 |
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
 Posted: Sun Jun 15, 2008 7:20 pm
[2.27] Bug - #PRINT stops the parsing of triggers
|
This was taken from http://forums.zuggsoft.com/forums/viewtopic.php?t=30906
DeReP stated that #PRINT stops his triggers from firing, and I'm just confirming it here.
Here is a simple test:
1. On the command line, type #TRIGGER {This is a test.} {#SAY Fired!}
2. On the command line, type #PRINT Testing.
3. On the command line, type #SAY This is a test.
4. On the command line, type #PRINT Testing two.
5. On the command line, type #SAY This is a test.
The output is as follows:
Testing.
This is a test.
Testing two.
This is a test.
Fired!
As you can see, it does not fire for the first instance. My guess is while #PRINT tells CMUD not to fire any triggers, it stops triggers altogether. This can have very bad side effects.
Charneus |
|
Last edited by charneus on Sun Jun 15, 2008 9:17 pm; edited 1 time in total |
 |
|
|
ralgith
Sorcerer
Joined: 13 Jan 2006
Posts: 715
|
Posted: Sun Jun 15, 2008 8:25 pm
|
But seems to turn it back on after a second usage?? Is it maybe toggling it instead of explicitly turning it off, then turning it back on when finished?
|
|
_________________
 CrossOver: Windows Compatibility on Mac and Linux CMUD Advocate |
|
|
|
DeReP
Adept
Joined: 14 Jun 2003
Posts: 222
Location: Chile
|
Posted: Sun Jun 15, 2008 9:18 pm
|
Im glad Im not the only one on this. Thanks Charneus.
I think the aproach on the #print command is very risky alltogether, disabling / enabling triggers should happen when outputing anything to windows. That string should have another property that triggers wont look into instead. |
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Sun Jun 15, 2008 9:24 pm
|
The approach isn't risky. It's just a bit faulty. Some people rely on #SAY, #SHOW, and #ECHO as triggers (the only difference between them being #ECHO sends it to the top window).
#PRINT was requested to do exactly as it does now. The only problem is it fails to turn parsing back on for the triggers. Other than that, I think it's a great command addition - that way I can #PRINT output to my screen without worrying if it's going to set off a trigger.
Charneus |
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Mon Jun 16, 2008 6:12 pm
|
Zugg, any chance this will be fixed in a very near future version? Maybe 2.27b?
Charneus |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Jun 16, 2008 7:02 pm
|
Bah, yes this was a stupid bug. I had code like this:
| Code: |
B := Pref.EchoMessage;
Pref.EchoMessage := true;
B1 := NoTrigger;
NoTrigger := true;
EchoInfo( Params);
NoTrigger := B;
Pref.EchoMessage := B1; |
Notice the bug? I flipped B and B1 when restoring the variables that are used to handle whether triggers are enabled. Yeah, that's what I get for not picking better variable names.
It's fixed for the next version, whether it's 2.27a or 2.28. Still deciding. |
|
|
|
|
|
|
|
