As you're using Ensemble, you can use class EnsLib.EDI.XML.Document. I don't have version 2015, but the following works on IRIS. I hope this is present in Ensemble 2015 as well. (Note that, annoyingly, method domGetValueAt is marked internal, and therefore doesn't show up in the documentation. I don't know how to achieve the same result without using this method.)

Set XML = "<a><b><c>some content</c></b></a>"
Set Path = "/a/b"
Set Doc = ##class(EnsLib.EDI.XML.Document).ImportFromString(XML, .sc)
If 'sc Quit $System.Status.DisplayError(sc)
Set sc = Doc.domGetValueAt(.Value, Path, "fo", 1)
If 'sc Quit $System.Status.DisplayError(sc)
Write Value,!

This outputs "<b><c>some content</c></b>" as you want.

Hope this helps,

I don't know if try/catch is slow, and I don't care. I don't use it because it is too wordy to handle errors exactly where they occur. It encourages code like in your example, where the code in methods is wrapped entirely in a try/catch block. You say the error object has all the information, but I disagree. It has some low-level information, but often lacks the context I need to determine what the problem is.

My preferred way of handling %Status errors is to add a %Status in front of it with more details of what happened when the error occurred, and return this to the caller. Somewhere up the call chain something will then handle the problem, e.g. add something to the Ensemble event log. This is such a standard way of working for me that I created a macro specifically for prefixing the new status information.

For errors that "raise" I also prefer $ZTrap+$ZError; I don't see the added value of try/catch here either.

I use %Status exclusively; I really, really don't like try/catch. The most important reason for me is that I want to add information about what went wrong to the status. In e.g. obj.%Save(), the returned status tells me that saving an object went wrong, and hopefully why. I want to add to this which object could not be saved, and possibly some other state that may be relevant for debugging the problem. I find this creates code that is easy to read and debug.

By the way, "If 'sc" is, to me, a lot easier on the eyes than "If $$$ISERR(sc)"...

$System.OBJ doesn't handle CSP pages, but $System.CSP does. You can use LoadPage:

Set sc = $System.CSP.LoadPage("/dev/test.csp", "duck")

(You need to use the URL here, not the class name.) This compiles the CSP page into a class, and then compiles that class.

Ah, I see -- yes, I can reproduce this, and I would think this is a bug. (It does work as expected in an "if", but not in a "case".) You may want to take this up with WRC, to see what they think.

As a workaround, are you aware that you can use local variables? You could assign the value of source.Items.(i) to a local variable, and use that in the case statement. Something like this:

In a switch statement like yours, this would probably save some typing as well. It does mean the lines in the DTL no longer display properly, though. (Although they might not anyway here.)


Can you cut this down to a minimal example (actual code)? What you describe seems to work here. What "doesn't work"?

If I iterate over a (list of) property:

this ultimately compiles to:

As you can see, the .(i) is replaced with .GetAt(i). (Note that I replace the default key "k1" with "i" here to match your example.)


Studio behaves really annoyingly if it loses its TCP/IP connection, as you described. I don't know how to prevent that. You probably don't have to restart HealthShare, though. When the crash happens, don't close the dialog immediately. Instead, first remove all locks for the process Studio was connected to; it shouldn't be too hard to find. (Something like System Operation -> Locks -> Manage Locks, I don't have access to a HealthShare instance right now.) Then allow Studio to reconnect, which should now work without issues.

This should have been the accepted answer. :) It is more important for code to be easy to read than for it to be easy to write.

I have enabled and used that feature in older versions as well; it is really useful. I have a PuTTY setup with a key pair that starts the IRIS terminal in docker on a remote machine, without any password, but still safe. (I wanted to use my regular account name as well, so I had to do some additional setup in the container, but the principle remains the same.)

Anyway, that explains why there's no need for a password anymore, thanks!

By the way, I have not een an announcement that 2019.3 became an official release, did I miss something? (I also see no Studio for 2019.3, and the 2019.4 preview Studio download doesn't work.)