 |
Aleron
Wanderer
Joined: 01 Aug 2005
Posts: 76
|
 Posted: Thu May 24, 2007 2:27 pm
[1.33] Variable Resolution
|
I'm having some problems with variables resolving the way I think they should.
| CMUD Documentation wrote: |
When you reference an Alias or Variable, CMUD first looks within the current class. If the alias or variable is not found within the current class, then CMUD looks in the Parent class. This continues until CMUD reaches the top level of your package. If the alias or variable still hasn't been found, then CMUD starts looking within other global modules within your package, or other published modules within other packages.
http://forums.zuggsoft.com/modules/mx_kb/kb.php?page=3&mode=doc&k=2695
|
That's pretty clear to me. However, I'm seeing behavior that contradicts that statement. Take the following scenario (which I created in a clean session):
| Code: |
test1 (module)
|- c1 (class)
| |- a1 (alias)
| |- v1 (value: 'c1: this is v1')
| |- v2 (value: 'c1: this is v2')
| |- v3 (value: 'c1: this is v3')
|- c2 (class)
| |- a2 (alias)
| |- v1 (value: 'c2: this is v1')
| |- v2 (value: 'c2: this is v2')
| |- v3 (value: 'c2: this is v3')
|- c3 (class)
|- a3 (alias)
|- v1 (value: 'c3: this is v1')
|- v2 (value: 'c3: this is v2')
|- v3 (value: 'c3: this is v3') |
The 'Set as Default when executing' option is set on all three classes for what it's worth, although as I understand this piece of documentation, it really only applies when a trigger/alias/macro/etc is adding a new setting without an explicit class name.
All three aliases (a1, a2, and a3) are defined as:
| Code: |
#SAY v1: @v1
#SAY v2: @v2
#SAY v3: @v3 |
So, if I understand the documentation quote above correctly, if I execute the a1 alias (which is in the c1 class), then I should see the following output:
| expected output wrote: |
v1: c1: this is v1
v2: c1: this is v2
v3: c1: this is v3 |
However, that's not the output I see. This is what I actually see:
| actual output wrote: |
v1: c3: this is var1
v2: c3: this is var2
v3: c1: this is var3 |
The documentation is pretty clear to me, which leads me to believe this is a bug. Am I reading it wrong, or is it written wrong?
I've been seeing this behavior in one of my scripts, so I created this example in a fresh session, and was able to duplicate the behavior. |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Thu May 24, 2007 2:44 pm
|
Confirmed. You're not reading it wrong, it really is a bug.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu May 24, 2007 7:46 pm
|
Looks like the "Set as Default" option is not working correctly. The above operation is the correct operation when this flag is off. When Set as Default is off, it looks in the *current* class first, which is defined by the #CLASS command and has nothing to do with what class the alias is within. However, when Set as Default is enabled, then it is supposed to use the class that the alias is within as the current class, and it looks like it's not doing this. I've added this to the bug list.
(although it looks like you have some typos in your last example, since "var1" should be "v1", etc) |
|
|
|
|
Aleron
Wanderer
Joined: 01 Aug 2005
Posts: 76
|
Posted: Thu May 24, 2007 8:45 pm
|
Yes, that is correct, those are typos on my part...I didn't copy/paste it as I was writing up the bug at work while testing it remotely on my home machine.
The script that I found this bug in works like I described above, except the aliases are triggers. These triggers (there are some in each of the sibling classes) use variables that are in their class as part of their patterns. So a question I have is, when CMUD is trying to find all the triggers that match a particular buffer of text so that it can execute them, does it temporarily bind the 'current class' to the class that the trigger is contained in before those variables are expanded for pattern matching purposes, or does it happen after the match is determined but before the code is executed? If it's the latter, then it would still be bugged. Well, as far as I see it it would. Although it would depend on how you define 'executing' in 'Set as default when executing.' |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri May 25, 2007 5:22 pm
|
No, triggers *always* execute within the current class of the window that received the text that caused the trigger to fire. There is no "Set as Default" kind of option for triggers. That's one of the big differences between triggers and aliases. If you need to access a specific variable in a specific class within a trigger, I suggest that you use the @/classname/varname syntax.
|
|
|
|
|
Aleron
Wanderer
Joined: 01 Aug 2005
Posts: 76
|
Posted: Sat May 26, 2007 7:40 pm
|
Ahh, I see. That clears that up then. :)
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
