|
Blerghass Beginner
Joined: 25 Nov 2001 Posts: 26 Location: USA
|
Posted: Thu Dec 27, 2001 2:54 am
Preventing a trigger from going off after T+ |
Basically, I'm wondering how to T+ a class of triggers so that those triggers will start acting when the next line comes in instead of on the current line.
Here's my situation. One trigger is set off by ^(*)GSM. This trigger in turn has the line {T+ barfclass}. "barfclass" has a trigger set off by ^(*)$. "barfclass" is disabled when the GSM line comes in, so the ^(*)$ trigger in "barfclass" doesn't go off immediately when that line comes in. But because the T+ line goes through, the ^(*)$ trigger in "barfclass" then goes off on the same line that caused the {T+ barfclass} in the first place.
#GAGging and "notrig" don't seem to help. Any ideas? |
|
|
|
Blerghass Beginner
Joined: 25 Nov 2001 Posts: 26 Location: USA
|
Posted: Thu Dec 27, 2001 11:08 am |
The partial solution I found after more tinkering was to {#sub ""}. This does not work, however, if you actually want to display the line as it was.
Also, I could pad the ^(*)$ trigger like this:
#trigger {^(*)$} {#if (@stat = 1) {do something; @stat = 0} {@stat = 1}}
This works because a trigger will only set off once per match.
A third but still imperfect option is to have the ^(*)$ trigger have higher priority, so it will not set off after the other trigger #T+'s it.
Is there any simple way to prevent any other triggers from going off on a given line of text? |
|
|
|
iljhar GURU
Joined: 10 Oct 2000 Posts: 1116 Location: USA
|
Posted: Thu Dec 27, 2001 8:36 pm |
That's one of the drawbacks of classes, in my opinion. As you experienced, a trigger turns on a class, that class has a trigger that catches everything and processes that line. Since the first trigger turned on the class it also gets processed inside the class. I don't know how to stop that "feature", but it looks like you may have found a good solution, setting a variable. Now, you probably don't want to reset the @stat var to 0 until right before you disable the class, just in case you happen to get more than 1 line before the GSM line comes in.
Iljhar |
|
|
|
Blerghass Beginner
Joined: 25 Nov 2001 Posts: 26 Location: USA
|
Posted: Thu Dec 27, 2001 10:23 pm |
I found another solution that is pretty robust.
I put all my "normal" triggers into one class, call in NormalClass. I then put a couple triggers in another class, call it OtherClass:
#trigger {^*$} {#T+ NormalClass; #T- OtherClass}
#trigger {^$} {#T+ NormalClass; #T- OtherClass}
(second one because ^*$ doesn't match the empty line)
Whenever I want a trigger to disable all other triggers from triggering on a given line, I simply put #T- NormalClass; #T+ OtherClass at the end of it (probably make it an alias just to save some time).
As long as OtherClass has lower precedence/priority than NormalClass, I think this works (my tests have gone fine). It appears to be very robust and pretty efficient. |
|
|
|
|
|