Hi @Daniele Monti, if there's no error message in the ObjectScript Output channel then you will need to capture a network trace. This will capture all REST traffic between VS Code and IRIS, so we can see the whole response to that request. I suggest you use wireshark or the Web Gateway's HTTP Trace tool. With the tool enabled, reproduce your issue. The turn the tool off and find the request that corresponds to that action. It will be a PUT on a URL like /api/atelier/v6/doc/UITXXPIEPAAdm.mac. The find the corresponding response. It should be a 40X or 500 response. Copy the entire body and post it here (hiding any sensitive information). That should tell us what the issue is.

If possible, you should use VS Code on a developer laptop that can be kept up to date instead of the server that IRIS/Cache is running on. The extension versions you are using are well over a year old and you'll be missing out on major new features, like the one you requested in this post. VS Code can connect to servers that are on a different machine.

@Pietro Di Leo 
If you find Wireshark intimidating you can use the Web Gateway's HTTP trace facility. If you're using Wireshark and the server is on the same machine as VS Code select the loopback capture device and add an http filter. This will help you filter out unwanted packets. If you use the Web Gateway's HTTP Trace, you can simply turn it on, attempt to save the class, turn the trace off, and then click refresh to see all the packets. You will be looking for a PUT request to the /api/atelier/v#/doc/<class_name> endpoint. We want to see what the full response is to that request.

Studio is still available from the WRC as an independent download. See this DC post for more details. I am happy to help you get VS Code working, but to know what is wrong I will need to see your code-workpsace file, server connection info and possibly a network trace since VS Code talks to IRIS via HTTP(S). If you're more comfortable doing that in private you can open a WRC case and they will help you. You can link this post there so they have more context. This feature has existed in VS Code for 4.5+ years so I think there's some sort of configuration issue and not a product defect. Also, any feedback on how we can make VS Code better can be communicated to WRC, your account team, or by posting an issue on GitHub.

Are you using client-side editing (your ObjectScript classes are in a local folder that you have open in VS Code), or server-side editing (files are edited directly on the server, like Studio)? This is important so I can give you the best advice for troubleshooting the problem. Which steps in the documentation did you follow to get this set up?

@Paul Hula 
Do you have in the InterSystems ObjectScript Extension Pack installed? The InterSystems Language Server provides autocomplete support for class names and class members. If you already have the extensions installed and are still experiencing this issue then you probably don't have a server connection configured. The documentation for doing so can be found here.

VS Code allows you to change the colors used in the editor via Themes. Documentation is here. If you're on Windows you can also load your custom colors from Studio using the "Load Studio Syntax Colors" command.

Hi Joel, thanks for the feedback! There's no reason why you couldn't have Prettier format your local files. It just won't work as well as it does for other languages because there's isn't an ObjectScript plugin (AFAIK), and some elements of class definitions (everything that isn't implementation code) is re-rendered after syncing with the server. I have looked at the "objectscriptQuality" rules before to see if there's anything that I should add to the Language Server extension and I came to the conclusion that it wasn't doing anything that was really valuable. If there are specific rules that you find useful I'd be happy to hear your thoughts, but I've resisted adding a bunch of Diagnostics/formatting options for "code style" issues  because many ObjectScript developers don't agree on them!

Thanks for the detailed post @Joel Solon! #Dim isn't necessary for many system percent variables because the Language Server already knows their types. The full list currently supported can be found here. %sqlcontext is not one of them, so please open a feature request to add that and any others that I might have missed. I also wanted to note that coming soon is support for variables passed by reference as method arguments, so even that case won't require #Dim.
 

Integration with the BPL and DTL will be available when the new versions of those editors are released. The VS Code integration will support client-side editing as well. The Rule Editor integration already does so.

You're mixing up what we mean by "client-side editing" and what git-source-control does to maintain files in Git. In VS Code, client-side editing means "editing files on my locla file system directly". git-source-control is used when you're editing files directly on an IRIS server, and it handles the projection to the file system so Git can pick up changes. These are fundamentally different development models that shouldn't be mixed. Mixing them can lead to files being out of sync and changes being lost or overwritten.

1. Connecting to any server is pretty easy so I'm not sure why we'd need to add a special case for dockerized IRIS.

2. Can you elaborate please? Are you referring to the lack of BPL/DTL UI integration?

3. This is incorrect. git-source-control is a server-side source control solution. You must use server-side editing to work with it. We do not and will not support the use of server-side source control classes with local files.