All
Accepted answers
John Murray · May 13, 2016 go to post

Maybe revise the message to read "Package name can contain dots but cannot start or end with a dot", or something similar.

John Murray · May 12, 2016 go to post

Thanks for your explanation Mark.

Interesting to know that the ZZW command was removed, leaving only the full-form ZZWRITE one. Our Command Line Extensions implemented ZZW and ZZWRITE as synonymous. Your ZZWRITE implementation takes precedence over our ZZWRITE but at least our implementation remains accessible via ZZW.

Ideally you guys would establish a policy one way or another, document it, then stick to it going forward, applying the rule consistently to commands, functions and system variables. In the past you've typically added Z* things but not ZZ* things, for example $ZCLASSMETHOD().

John Murray · May 12, 2016 go to post

Thanks for posting this. I shall try and remember to use the link routinely for my exploration of the docs, as a way of testing the beta.

John Murray · May 12, 2016 go to post

Yes, a useful command but I think it's inconsiderate of InterSystems to be annexing the ZZ* command-space. The facility for sites to extend the language with their own commands by writing a %ZLANGC00 routine (see here) has been useful and we at George James Software have for many years offered a free download called Caché Command Line Extensions. We deliberately made all our commands begin with ZZ in an effort not to clash with future InterSystems extensions, but our ZZW extension was subsequently overridden by the ZZW command InterSystems added in 2013.1. It seems it's only a matter of time before you sequester other commands from us.

John Murray · May 11, 2016 go to post

For the information of anyone watching this thread, 1.0.158 appeared on the update site within the past 24 hours. It resolves the huge icon issue, and probably contains some other goodies too.

John Murray · May 11, 2016 go to post

For those of us outside InterSystems, 1.0.145 and 2016.2.0.645 are the latest versions currently available.

EDIT: I typed too soon. It turns out 1.0.158 was published on the update site overnight. Maybe Mike's problem will be resolved by him updating to that.

John Murray · May 10, 2016 go to post

Any idea when we can expect the next update? I don't mind the oversize menu icon, but it's more than two weeks since "Check for updates" in Atelier gave me anything new.

John Murray · May 10, 2016 go to post

Nice article. One comment: I get nervous when I see code that swaps namespace without taking steps to swap back again afterwards.

John Murray · May 3, 2016 go to post

Travis, are you aware of our well-established native Caché/Ensemble/HealthShare source code management and deployment tool? Previously known as VC/m, it's now called Deltanji.

As well as dealing with code versioning Deltanji also handles deployment. It integrates with Atelier, Studio and Portal.

Some members of this Developer Community may be willing to share their experiences of using our tool.

Perhaps you have specific reasons for wanting to go with Git, but it might be worthwhile considering Deltanji as an alternative route.

John Murray
George James Software

John Murray · May 3, 2016 go to post

Maybe your code at someLabel^someRoutine in OTHERNAMESPACE calls another routine that exists only in OTHERNAMESPACE. In that case, the <NOROUTINE> error will occur when the call is made. That's because when you d someLabel^|”OTHERNAMESPACE”|someRoutine(inputVar,.resultByReference) you are fetching the routine someRoutine from the database of the OTHERNAMESPACE namespace, but you are executing that code in your current namespace.

This is not the same as swapping to OTHERNAMESPACE, running the code, and then swapping back. For example, if someRoutine accesses globals it will do that from whichever namespace is current.

To see an example of this, try the following:

SAMPLES>w $zv
Cache for Windows (x86-64) 2016.2 (Build 636U) Wed Apr 13 2016 20:58:35 EDT
SAMPLES>d main^lookup
 
Lookup: 1-jan-2016...finding birthday...no matches
Lookup:
SAMPLES>zn "user"
 
USER>d main^|"SAMPLES"|lookup
 
Lookup: 1-jan-2016
<NOROUTINE>main+27^lookup *datent
USER 4d1>
 
USER 4d1>q
 
USER>

The code in main^lookup in the SAMPLES namespace calls $$validDOB^datent. When this is attempted from the USER namespace we get a <NOROUTINE> error. Notice that the extended information in the error tells us that the routine it can't find is datent.

John Murray · Apr 29, 2016 go to post

The port info is also available from the "About" link at the top of Portal:

John Murray · Apr 25, 2016 go to post

I suggest you use the %IsA classmethod that every class inherits from %Library.SystemBase.

With this I think your method becomes very simple:

 quit $classmethod(className,"%IsA",..#UTCLASS)

John Murray · Apr 21, 2016 go to post

That doesn't look right. Here's what I get from "Add to Project" off inspector.csp in the /csp/samples app in my SAMPLES namespace:

 

On that first dialog I choose the project to import to (GS2016). The next page looks like this:

 

I'm using Atelier 1.0.141. What build is yours?

John Murray · Apr 21, 2016 go to post

How about using the Server Explorer view in Atelier to locate the CSP file, then right-clicking and choosing "Copy to Project" ?

Incidentally on my Atelier (1.0.141 on x64 Windows) there's a noticeable lag (about 5 seconds) between the right-click on the CSP file and the appearance of the context menu.

John Murray · Apr 21, 2016 go to post

I agree about the value of Studio projects. Our Deltanji source code management product (hint - Solo edition is 100% free) is able to generate Studio projects automatically that match the Deltanji Change Requests which represent the enhancements/fixes you're working on and propagating through your dev/test/deploy cycle.

John Murray · Apr 21, 2016 go to post

Somewhat related to this, I think there's still a useful role for %Studio.Project projects as ad-hoc server-side collections of classes etc that can be assembled independently of your package hierarchy, which typically has to remain far more static. But it's not yet clear to me how these projects (which after all are more correctly called "Studio projects") will evolve/mutate/expire in the brave new world of Atelier.

John Murray · Apr 12, 2016 go to post

Thanks to James for a prompt and detailed reply to my breakfast table question. Here I'm going to add this link to a previous posting of mine about %ALL, in part to highlight that %ALL mappings don't apply to 100% of the namespaces you have. The DOCBOOK and SAMPLES namespaces are apparently exempt. I can rationalize the DOCBOOK extension to myself, but the SAMPLES one puzzles me, especially given that the ENSDEMO namespace of an Ensemble or HealthShare instance is not exempt even though it's effectively another "samples" namespace.

John Murray · Apr 8, 2016 go to post

I found the same, i.e. clearing cache was necessary but after having done that my FF no longer stops responding when I go into the tags field of a new post.

John Murray · Apr 8, 2016 go to post

Given that John Willeke reports the "+" feature arrived in 2016.1, is that version of Ensemble also affected by this bug? I don't currently have a 2016.1 Ensemble to test.

John Murray · Apr 8, 2016 go to post

On my Atelier (1.0.131 on Windows) I have a Server Explorer view on the Atelier perspective:

As well as offering + and x buttons with which to add and delete connections, it also gives me access to the properties of a connection for amendment.

If you don't have the Server Explorer tab visible, look for it as an option on Window\Show View

John Murray · Apr 7, 2016 go to post

Francis, I think the idea of the "Developer Community Feedback" community/group is to discuss the behaviour of this community.intersystems.com website software.

I think your posting belongs better in the "Caché" community/group because that is the base product from InterSystems in which COS is implemented, and upon which Ensemble, HealthShare and DeepSee (which each have a separate community/group) are built.

John Murray · Apr 6, 2016 go to post

No, it even happens when I have no source control class set for the namespace (and have restarted my Studio after confirming that).

John Murray · Apr 6, 2016 go to post

Odd then that when I click the Compile button the suffix disappears while compiling but then reappears afterwards, even though the Output tab reports successful compilation.

John Murray · Apr 2, 2016 go to post

Here's what the Properties tab shows when I select my Samples project in Project Explorer:

Is yours not doing this? If not, what Atelier version do you have? Mine is 1.0.128

John Murray · Apr 1, 2016 go to post

Atelier projects aren't really created in namespaces. But if you expand the project in the Atelier Explorer tab you'll see information about the connection it's associated with. An attribute of the connection is which namespace it connects to on the target server:

John Murray · Mar 22, 2016 go to post

I updated to 1.0.123 today and things are starting to function in this area. I understand it's a work-in-progress, but I'm glad to start testing it.

The Tools menu now offers two options, "Add-Ins" and "Templates". Both lead to a dialog titled "AddIn Template Wizard". First wizard page asks me to choose which connection to use. Second page has subtrees titled "Recently Used", "Custom Used" and "Stanard Add-Ins" (sic).

"Stanard Add-Ins" lists the same entries as I get from the equivalent Studio dialog, which is cool!

Some of my own add-ins that appear in this list seem to work without requiring any changes - also cool!

I have one that fails in Atelier but works in Studio, so I've opened a WRC ticket.

Keep up the good work.

John Murray · Mar 22, 2016 go to post

Understood. Consider me a beta tester of this feature, which is important to us at George James Software.