|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Wed Jun 11, 2008 9:42 pm
[2.26] Trigger priority request |
I have often been irritated that I can not set the priorites for sub states of trigger to be earlier then its parent state. A very common usage of multistate triggers is to match a beginning line, then capture all lines until an ending indicator. In this situation we know that the only trigger we want matched is our capture, this means setting the priority to 1 and setting the stop flag. However the parent trigger for our capture is often very specialized and likely to not be used frequently. This means we want the parent trigger to be a late priority like 10000.
Currently the only way to make it work is to use an #ONINPUT trigger as the primary since we can set the priority to 1 without affecting incoming line testing. Then match our opening line with priority 2, and use priority 3 for the actual capture. This of course doesn't work when the data being captured is not sent as a response to a command.
My suggestion is to remove the use of priority as a determining factor for which trigger state is above which. Use the Parent field in the database to record the order of the states, and the Owner field to record which trigger they belong to. That would make this structure:
Trig a
Cond b
Cond c
Cond d
Look like this:
a-Owner=class|Parent=class
b-Owner=a|Parent=a
c-Owner=a|Parent=b
d-Owner=a|Parent=c
This readily allows the substates to be attached by querying the Owner field to get a small list of those that belong to a given trigger, and actually lays a foundation for nesting of trigger states. |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Jun 11, 2008 9:55 pm |
I'll give that some thought. As you mentioned, each trigger state *does* have it's own priority setting in the database, but this is currently used to set the order of the states. Using the Parent field directly as you suggested doesn't work because the TreeView is already using the Parent field to set up the Tree display, and the Owner field is already used extensively in CMUD to reference the *class* of the setting, so I cannot set the Owner to be the parent trigger...it *must* be set to the class.
So, I'm not sure I can do this without using another database field, which is why I used the priority field in the first place. And unfortunately, nesting of trigger states would be *very* difficult with the way they are implemented elsewhere in CMUD. A trigger state actually has a completely different object-class than a parent trigger (in terms of Delphi classes). And I honestly don't know that it would ever be useful enough to justify the huge amount of work for it.
In any case, I've added it to the wish list and I'll see if I can figure out a way to do it.
Edited: Actually, it looks like I already have a field for the state number, so I'm not sure why I'm also using the Priority field for that. So it might be easier than I thought, but it's not something that I'll do for 2.27, sorry. |
|
|
|
Fang Xianfu GURU
Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Thu Jun 12, 2008 12:06 am |
Nested trigger states doesn't really seem to fit with the current model. They'd be a state that's only active if their parent state fires? But their parent state has to fire, because the trigger moves sequentially. If you want to do something else, you generally use the #state command or a separate trigger.
|
|
|
|
|
|
|
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
|
|