Hi @Scott Roth, when 2023.2 is released VS Code will support an integrated WebSocket-based terminal that's implemented as a new Atelier API endpoint. It will be available in kits by default and the vscode-objectscript. It's documented here and the newest beta version of the vscode-objectscript extension and 2023.2 previews have the needed code.
@Michael Gosselin
The best place to report those issues is the GitHub repository for the Server Manager extension. Also, any details you can give us would be great. Does a server already exist with that name in your user settings? Do you have a workspace open?
cc @John Murray
InterSystems is working on adding support for XML import/export in the Atelier API with integration in the VS Code UI via commands. I will post the PR here when it's opened and a suitable kit is publicly available.
@Evgeny Shvarov
It's available on the VS Code Marketplace, which is where people would expect to find it.
Hi @Michael Davidovich, I can show you how to configure VS Code to see system classes. Are you using client-side or server-side editing?
Hi @Josef Zvonicek, I'm glad that VS Code is making you more productive, and thanks for the feedback. I have some comments about your fine-tuning list:
@Anna Golitsyna
I think the debugging experience in VS Code is actually better than Studio since you can view the properties of OREF's in the variables view in VS Code but not Studio. You can have that developer file an issue report on GitHub, or contact the WRC if you have a support contract.
As for features in Studio but not VS Code, the biggest one is the Inspector. It is very unlikely that it will ever be implemented in VS Code. VS Code also does not support integration with the legacy Zen BPL and DTL editors. VS Code will support integration with the new Angular versions of those editors when they are implemented. VS Code also doesn't support syntax coloring for Cache Basic or MultiValue Basic, but you can still edit those files.
@Anna Golitsyna
The big plus is that VS Code is in active development, while Studio hasn't seen enhancements in years and now is deprecated. Other than that, here are some benefits of VS Code:
Just to clarify for everyone, Studio source control classes that import/export XML files will continue to work and be supported. There just won't be a menu option in VS Code to export files as XML.
@Larry Overkamp
VS Code does not support exporting or importing source code as XML files. There are existing tools in the terminal and SMP for that. The server-side editing paradigm that John mentioned above is conceptually similar to Studio in that the files you edit are "virtual" and do not need to be exported to the file system to be edited. It supports viewing all files in a namespace like in Studio, and it also supports importing local .cls, .mac, .int and .inc files into that namespace.
Searching for text across those virtual files is supported and the UI is much better than Studio since you can click on the match and jump right to that location in the file. Enabling that feature requires some extra steps due to a VS Code core limitation, but this is something that we anticipate will be resolved in the future.
@Anna Golitsyna
We have a documentation page that describes some useful features for migrating from Studio that you may find useful.
@Richard Filoramo
The server-side editing paradigm in VS Code is conceptually similar to Studio in that the files you edit are "virtual" and do not need to be exported to the file system. This mode supports Studio source control classes, so you can continue using them if you want. We have a documentation page that describes some useful features for migrating from Studio that describes where the Studio source control integration can be found in the VS Code UI.
@Mikko Taittonen
The vscode-objectscript extension does provide New File commands for Interoperability classes. You can read the documentation here. The SOAP wizard can be accessed from the Server Actions menu. BPL and DTL classes can be edited textually. Support for the graphical editors will be added when they are rewritten using Angular. For a preview of how that would work, you can try out the new Angular Rule Editor in VS Code.
@Alexey Maslov
That sounds like a bug to me. Can you file a GitHub issue with steps to reproduce? It would also help to know the versions of the extensions you have installed, the version of IRIS you're connected to, and the text of the file that you see the bug in.
@Menno Voerman
Unfortunately I don't think this is possible. That command is for opening files, and technically the name of the file is "HS/FHIRServer/Interop.HTTPOperation.cls", not "HS.FHIRServer.Interop.HTTPOperation.cls".
@David Hockenbroch
We just improved the UI for creating a new server-side editing workspace folder. If you have no workspace open, you can follow the steps here to create a new one. If you do, you can add a new folder to you workspace by right-clicking in the file explorer and selecting "Add Server Namespace to Workspace..". That command will follow steps 4 and on. To see CSP files, select "Web Application Files" in the menu from step 8. To see basic files, select "code files in <NS>", then select "Filter", then make sure your custom filter contains the "*.bas" pattern. It can include other file types as well.
@Martin Fukátko
I tried reproducing your issue but couldn't. I see your using client-side editing (editing a local file). Have you saved that class on the server? The Language Server extension checks for class existence against the list of classes on the server so if yours hasn't been saved, it technically doesn't exist.
@Norman W. Freeman
This query will return the names of all non-system and non-generated classes in the current namespace:
SELECT Name FROM %Library.RoutineMgr_StudioOpenDialog('*.cls',1,1,0,1,0,0)The documentation for this query and its parameters can be found here.
@Ben Spead
The existing docs here have been updated to reflect the new UI.
I expect that this will work fine. Our 'Open Error Location..." command just goes to the line+offset in the INT routine, it doesn't try to resolve the location in the CLS/MAC/CSP that generated the INT.
Here's a full list of all the MimeTypes that will be correctly colored in VS Code (requires InterSystems Langauge Server version 2.1.1):
An XData bock with no MimeType will still be colored as XML.
@Scott Roth
Please see our documentation page on server-side editing for directions for setting up your workspace.
I just released InterSystems Language Server version 2.2.0, which provides intellisense for variables created by %New(), %Open() or %OpenId(). VS Code should auto-update it for you.
Maybe try using 'ck' instead of 'cuk'. The 'u' flag is the one that tells the compiler to not recompile if it doesn't detect a code change.
@Zach McKinney
Thanks for log output. Have you compiled that class? The "Breakpoint Cannot Be Mapped" error means that the debugger couldn't map that location in that class to the generated INT routine.
@Zach McKinney
Please follow the steps listed here and send me the log output. Feel free to mask any sensitive information.
I opened a pull request to improve the documentation so other users don't have the same confusion
That's the problem. The folder setting is relative to your workspace root. Since you have repos open, you want it to be "PATS\Server\Namespaces\AXIS".
Which folder do you have open as the root of your workspace?
Did you export those files using the VS Code extension? The extension uses its export settings to determine where it will look for local copies. For example, if you have the AXIS folder open in VS Code you would need the following export settings to reflect the existing folder structure that you have: objectscript.export.folder setting equal to "", objectscript.export.atelier setting set to true, and objectscript.export.addCategory setting set to false.