Zugg Software :: View topic - why Cmud define a new existing variable ?

Beginner Joined: 07 Oct 2010 Posts: 15

I have many different variables with different names and put them into different folders, so I can check them easily.

But after a while I noticed that some of those variables (only 1 or 2 of them) are defined again by Cmud. And the one I defined was not used. Why?

Wanderer Joined: 02 Sep 2005 Posts: 85

any duplicate variables? open #class editing? (I do that sometimes) that's all that comes to mind right now

Wizard Joined: 22 Mar 2007 Posts: 2320

There are numerous possibilities.
1) If any of the classes that a variable resides under is disabled, that variable will be invisible. Setting the variable will create a new one.
2) If a trigger uses the #CLASS command to change the currrent class, setting a variable might create a new one.
3) If there are variables with the same name in different classes, different functions might choose a different variable depending on the scope of that function.
4) If a variable is defined within a window (instead of a module), commands defined in other windows will not see that variable and will create a new variable.
5) If some of your commands run in parallel threads (i.e. you use commands like #WAIT or #THREAD), different threads might try to access the same variable at the same time. This can result in new variables.
6) If you are running a very old version of Cmud, there were some bugs (a long time ago) that resulted in unintended new variables. However, neither versions 2.37 nor any 3.xx version have shown any bugs of this sort.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Check the compiled code tab of your setting to see what CMud thinks it should be doing. When it points to the correct variable, you should see a "(class name)" where name is the class that the variable is in. If name is something different, then CMud is stuck (as of the time of compiling) on some other class folder and ALL references to ALL variables (or, at least, more than just this one variable) will point to that class.

This class it's stuck on doesn't necessarily have to be enabled, and the variables this issue creates will always end up in that class (again, regardless of enabled state of the class.)