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.

Hi Dmitry,

As I mentioned we are still working to complete all functions in the COS parser. I will make certain the developers are aware of this syntax error.

Hi John - I saw something similar when I ran update but in my case I did not get the signing warnings. I will pass this along to the right people. Thanks!

You can jump from code you are looking at to referenced calls via the Ctrl-F3 shortcut. Studio's "GoTo" feature which allows navigation to a specific line+tag will be included in the 1.1 release.

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.

I did this as well but set it up with https which I found to be much simpler to do.

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.

 

 

We looked at and abandoned that approach in the early days because it is not flexible enough. You get only a single projection for a given class and any changes to it require a recompile of the class. Compose() is an attempt to move past those obstacles.

Michal - if you can wait it might be better to stay on your current kit and then pick up the 17.1 FT as an update in 8-10 weeks?