I make every effort to take a passive role here on the community but I have to make a statement here. What you are saying is that regardless you are leaving people with a broken experience. If Atelier does not get the added editors needed to support HealthShare development fully with integrated source then its appeal is greatly diminished as you have large pieces of work that miss out on integrated source control. But you can't go back to Studio either as it leaves you with no supported plugins for ANY source control system at all and means you have to make that implementation yourself via Studio Hooks. Neither of these situations is viable unless your intent is to leave people with no forward path for managing code and developing on ISC technology using any modern professional development approach.

Herman - there is a place to report issues. Its the same as anything else with our product. The WRC is fully supporting Atelier and issues are tracked in the same manner as any other part of the product. We are encouraging general conversation here because it is of benefit to everyone and not specific to Atelier as a policy point.

 

As for choosing Eclipse. It boils down to ecosystem. The editors you mention are all nice but none of them support the entire range of features we can get from Eclipse. You will note that by adopting a REST api we left it open for ourselves or anyone else to expand the functionality of any popular IDE on the market for use with our products.

This really boiled down to the band aid removal technique. The existence of a switch implies people are not under any pressure to make changes to their code. It gives them a reason to wait. The longer we left this in the longer we had to support it and the more questions about why something might work in one syntax but not the other. I hate causing partner's pain but in this case the sooner the better.

There are multiple steps required here.

1) The two csp applications that support the Zen app and the REST app must both be defined to store their license information ( cookie ) in the same location on the browser.  You will need to make sure you have enabled cookies for sessions and that both apps put the cookie in the same location.

2) In the CSP Rest page you must tell the csp server logic that you want to use sessions. To do this you need to ovverride the parameter "UseSessions" and set this to true. This will persist the session from call to call and will look for and update the session cookie in the http request.

So you might do something like:

/csp/mynamespace as the URL for the zen app and then have /csp/mynamespace/REST for the rest calls..

Both would store the session cookie at /csp/mynamespace

This should get the same license and user allocated to both applications.

Just in case you are asking about why Cache has .mac files and .int files. These are shorthand for macro and intermediate. Both are routine files but have different roles at compile time.

A mac file can contain macro code like $$$InsertCodeHere. When this routine is compiled in to intermediate code the macro has been evaluated and replaced with actual runnable objectscript code like

write !,"Bill was here"

You can only use macros in .mac routines.  Classes support macros because they get compiled in to .mac's and then generate INT code