Atelier custom $variable support

On a system I have been working there are some custom special variables like

do $example.DoSomething()

Some code requires a

set x=$example.SomeProperty

call e.g. 

My problem is that atelier doensn't seem to be able to properly recognize this code. 

If i have to use a call like this it breaks the entire code completion / code checking of the file.
Does somebody know a way to index these variables in atelier or manually add them so I can work with syntax checking and code completion? 

With kind regards 

Martin Weber

  • 0
  • 0
  • 100
  • 5
  • 0

Comments

I haven't tested this myself but from looking at past bug reports I believe that starting with Atelier 1.2, custom variables defined in a ^%ZLANG routine should parse correctly in Atelier as long as they start with a z.  The Atelier parser is expected to accept functions and special variables that start with $Z, and commands that start with Z.

Do your custom variables start with z? Can you also send your versions of Atelier and Eclipse?

Thanks for your reply!
Yes the variables start with z. Set x=$zsomething also works fine. But one particular z is an object so it is possible to say $zsomething.SomeProperty. This is where the syntax checking breaks. 

My Atelier version is  1.3.141.
Eclipse is on Photon

Hi Martin, thanks for the additional explanation. I was able to reproduce this on my system with custom variables defined in a %ZLANGV routine. I will report this internally to the development team.

In the meantime, the workaround I came up with was to set a local variable equal to the $z custom variable then work with that local variable instead. For example this did not throw any syntax errors on my Atelier client:

    set var = $zsomething

    write var.Property

    do var.Method()

I'm not sure whether you are seeing this when writing new code, where this should be easy enough to implement, or if you are working with an existing code base, in which case this would likely be a bigger undertaking.

I do not see this behavior when working with custom functions that return objects. So again if this is new development you could consider defining custom functions using a %ZLANGF routine instead of variables in %ZLANGV.

Thank you very much for all of your help and your worakrounds.
I will definitely use them.
 

Dear Martin,

I have a rather clear vision  where your $example comes from ($zzg, $zza, ...)  wink
My personal suggestion is to move everything you maintain today in %ZZLANG?00 routines into clean Macro definitions (.inc)

The history of %LANG* code goes back to times when migration from other language dialects (MSM, DTM, DSM, VISOS, ..) happened
and developers were writing just in  .INT routines. That's far back in the late 80ies.  The availability of MACRO code (also ages back) made it almost obsolete. The feature was never eliminated by considerations of backward compatibility. 

I personally would never allow any developer to touch %SYS. 
And wouldn't accept any code using $zz* , zz* stuff or $zu().
There are much cleaner ways to achieve the same result without compromising the core.