Zugg Software :: View topic

Apprentice Joined: 26 Apr 2007 Posts: 113

I reported this back in 1.34, but with no joy given that it was difficult to reproduce. (And still is.)

basically, in my package I have a single window and several classes. I normally keep all variables and so on in classes. However, due to various different reasons, variables get created outside of the classes, meaning they're simply in the window.

Most of the time this is fine, but I have come across instances of variable calls calling the wrong variable, if there's variables in a window that are unclassed.

It all looks fine in the package editor, however, if you check #VARIABLE variable1 via the command line. In my example I was trying to check #VARIABLE dissonance and got..

Apprentice Joined: 03 Nov 2007 Posts: 132

Yes. I have a thread on it actually. It's extremely annoying.

Posted: Tue Nov 13, 2007 5:39 pm

Malach, can you post a link to your thread on this? It sounds like what Asilient is saying is that the #VAR command is showing the wrong variable. He did "#VAR dissonance" and got the result for "#VAR LA_balance". This means that somehow his table for looking up variable names has gotten totally messed up and corrupted. I'd love to know how this would happen and have never seen anything like it myself.

The only way I could see the hash table getting confused is if you are creating multiple variables of the same name, and then renaming them somehow.

Apprentice Joined: 26 Apr 2007 Posts: 113

Well, it's the same for ALL referencing of variables. (except setting them, apparently.)

For instance, in my curing I have..

#SWITCH (@dissonance=1) {eg}

So if my alias with that in it got called while LA_balance was set to 1, I'd try eating goldenseal. The only way I could verify this is happening is by checking #VAR variable and see if the result was wrong.

I -can- send the package that the variables have been wonky on, but I deleted the offending variable, there may be others that I simply haven't discovered this behavior with yet.

Posted: Tue Nov 13, 2007 7:54 pm

Definitely send the package it you still have it. If the problems persisted after reloading the package then that means the package itself is corrupted and it's not just the internal hash table that I mentioned above. And if the package is getting corrupted I want to see it so that I can figure out what's causing it and also try to automatically fix the package when it is reloaded.

Apprentice Joined: 26 Apr 2007 Posts: 113

Sorry it took so long. I sent the package to you via email, in any case.

I'll try things in a new package, see if I get the same result.