We are learning not to launch a file until after receiving authorization from PanX headquarters. Doing so appears to invalidate global variables. We found that if a global variable is null, then the function Uniqueid(, which calls that variable, writes the error message to the disk (database) instead of issuing an error message. At least this is my observation.
Sorry, I cannot make heads or tails of this report. Global variables are not invalidated – if they were, Panorama would immediately fail, as Panorama itself relies on them.
I also don’t understand why the uniqueid( function has anything to do with a global variable anyway. That function is usually used with a database field, not a variable. And then what do you mean by “writes the error message to the disk (database)”? Did you find an error message in a text file? Perhaps not, since you mention database. I’m afraid I have no idea what you mean.
Jim, it has to be a huge challenge to try to interpret some of these posts, especially when the author is so limited as this one. For some time we have discovered that global variables are randomly not initialized as expected when launching a shared file to start PanX. (Today I tried to replicate this, but I was not able to do so). I started having strange trouble with one of my databases when a global variable was not initialized in the .Initialize procedure. Specifically, a global variable used in the Uniqueid( function was null or not initialized. For example:
FIELD = uniqueid(“FIELD”, GLOBALVARIABLE)
I discovered that Uniqueid( was writing an error message to field instead of an expected unique record number. Here is a png showing the error message written to the record.
I saw your recent post “Launching Panorama by double clicking on a shared database may not consistently connect to the serve.” I wonder if my observation of random un-initialized global variables could be related.
In Summary, I am talking about two issues. The first is observation that a shared file can be launched, and the .Initialize procedure randomly does not initialize a global variable. The second issue is the result of the uniqueid( can write a message to the field depending on the contents of the Root of that function.
One way that a global variable could fail to be given an initial value is if a fileglobal, or windowglobal variable with the same name is in scope at the time that you attempt to give it that initial value. It would be the variable with the more limited scope that would receive that value.
A form object that sets the value of a variable will also create that variable as a fileglobal, if a variable with that name doesn’t already exist, or isn’t in scope at the time that the form opens.
The error would occur if you subsequently moved to a database or window where the global variable was the only one in scope, and you attempted to use the variable in a formula.
You are correct, the uniqueid( function doesn’t handle errors in the root formula properly.
I’ll fix this, but I don’t think the fix will help you any. This is a situation where you absolutely cannot tolerate an error. What I still don’t understand is why you are using a global variable as the root. How are you setting the value of this global variable? The documentation suggests using a formula that will be unique for the computer, for example info(“computername”).
If you want to generate a unique value, I would suggest the more modern info(“guid”) function, which will generate a value that is guaranteed to be unique on the local network.
Also, I completely agree on all Dave’s points about global variables vs. fileglobal variables. You might want to review “The Life Cycle of a Variable” on the Variables help page:
Also, if you have access to videos from the Intensive Training Course from a few years ago, the Fields & Variables session discusses this topic in detail.