If you set up a server-side-editing workspace accessing a namespace for which your class is the source control class, you should see these buttons at the top of an open class or routine:

Also these entries on the document's context menu:

Each will open a quickpick top-centre of your window. The "Server Source Control..." one will show menuitems from the %SourceMenu and %SourceContext menus in your XData block. The "Server Command Menu..." will show menuitems from all other menus in that block.

No, nothing changed. When the "Choose Server and Namespace" button appears in the Explorer view (the VS Code Explorer, not to be confused with the ObjectScript Explorer) it's because you don't have a workspace open.

After clicking that and working through the input prompts you now have an untitled (i.e. unsaved) workspace consisting of a single isfs-type root folder.

When you created the new file in the Explorer tree and named it (for example) foo.mac you should see a new file tab open with a first line like this:

I'm guessing you deleted or replaced that first line. Don't do that. Rather, start coding your routine at line 2. The first line is essential and should not normally be touched.

I feel honoured that Server Manager 2.0 achieved first place in both categories. Building good tools for developers has been a major part of my professional life for nearly thirty years, so I am pleased this one is proving popular.

Thank you to everyone who voted for me, and to my employer George James Software for allowing me to work on this during office hours. Congratulations to Lorenzo, Henrique and José for their successes. There were some really great entries in the contest, so take a look at them if you haven’t already.

Maintenance release 2.0.2 is now on Marketplace, so your VS Code can easily update to it. Here's what it contains:

  • Support Alt / Option modifier on Edit and View buttons to add workspace folder for server-side web application files.
  • Add newly defined server to the 'Recent' list.
  • Handle repeated use of the same Edit or View button better.
  • Notify user if ObjectScript extension is missing.
  • Add more information to README.

Thanks for all the votes this entry has received so far.

Sounds like you are using the client-side editing paradigm. As Dmitry says, unless you haven't installed Language Server it will be LS that initially handles your "Go to Definition" request. But I think LS then calls an API entrypoint named serverDocumentUriForUri in the main ObjectScript extension (OS) to find out where the target document should be fetched from. As the API name indicates, this returns a uri (a document reference) that always fetches code from the server. And since you are using the client-side editing paradigm the fetched code cannot be edited.

Please open an issue on the repo at https://github.com/intersystems-community/vscode-objectscript/issues where it can be tracked and managed better than in this DC post.

If the BE guys are currently all working on the same copy of the codebase in a shared namespace on the production server, I think it will be an easier transition if they adopt server-centric source control such as Deltanji from my employer George James Software. They could start off by putting the production namespace under source control, then evolve to an architecture where development happens in a different shared namespace (could be on the same server, or on a different server), or separate namespaces for each developer, feeding an integration namespace where testing happens. Deltanji is very flexible and configurable, plus the configuration can be changed as the team's needs change. It integrates with Studio and VS Code editing tools.

Evaluation copies of Deltanji are available, and we're happy to set up PoCs for development organizations who are interested in trying it out for themselves. We can put people in touch with existing users, and some of those users might post a response on this thread too.

John Murray
Senior Product Engineer
George James Software
https://georgejames.com