Question How to check if a shared variable has been defined or not?

1. Define defined.
2. Check from where?

Easiest way to know if a shared variable has been defined or not, is not to use shared variables.
 
The references to variables are resolved at compile time. As soon as you try to run a program that has a shared variable defined which has no pendant defined somewhere up the call stack you get a runtime error. There is no functionality in the ABL that I can think of or know of which would provide a functionality to prevent such runtime errors. Other than your brain, of course.

Therefore to most shared variables are evil and we generally try to avoid them whenever possible. But that is another story.

If you must use them due to legacy code that makes use of them, you need to know what you're doing. Good luck!

Heavy Regards, RealHeavyDude.
 
This is not really the same thing, but you could RUN the program you are worried about NO-ERROR and then see if ERROR-STATUS:GET-NUMBER(1) equals '392' (the error# for a shared variable problem).

Then you could run another program that contains DEFINE NEW GLOBAL SHARED, and then try the first one again (though, that would be a strange way of doing things).

IIRC, this error is only raised if the target program *uses* (eg. DISPLAY, ASSIGN etc.) the variable in question. Merely DEFINEing it won't trigger an error (I think).
 
First of all shared variables are a really bad way to do things. You shouldn't do that.

But if you're going to do it anyway or you need to accommodate someone else's bad design...

IMHO the only sensible way to use shared variables is to always define the NEW GLOBAL SHARED.

That way you never have to worry about if was previously defined.

If you are the first program to reference it then it gets created.

If someone else beat you to it that's ok, the existing GLOBAL is used, nothing new is created and the "initial" phrase is ignored. NEW does no harm when used to define a "global" shared variable that already exists.

If you are using shared variables that are NOT "global" you have big problems. Don't do that. There is a copy of that shared (non-global) variable for every instance of NEW. There is a stack maintained so that the runtime knows which one is available at any given moment but it is a confusing maze of twisty passages that you will get lost in. And if you define them in persistent procedures you're *really* going to regret it.
 
You must log in or register to reply here.
Back
Top