Zugg Software :: View topic - [1.26]#EVENT needs an ID field so that #T- can work properly

Beginner Joined: 09 Dec 2004 Posts: 10

I would really like for events to have an Id. for me, not being able to use #T- on a specific event has really limited the usefulness of this feature.

example:

i use a trigger to detect the prompt and then use #RaiseEvent Prompt
now i have a Prompt event that is always enabled. but in some situations, i would like to hook another event onto the Prompt temporarily. say i would like to enable some trigger and then disable it when the prompt event is raised.
once that happens, i want to turn off the event until the next time i need it, but if I #T- Prompt, it seems like only one event gets disabled, apparently the newest one?
i would like to be able to control which one is enabled/disabled.

on that note, it would be great if there were some way to disable the current trigger or event like #T- this or #T- me (if there is such a thing, please enlighten me)

Posted: Sat Mar 10, 2007 2:02 am

Couldn't you just have an #IF statement in the prompt event that if true, would raise the other events?
Granted, thats only a workaround, all setting 'should' have an ID.

Posted: Sat Mar 10, 2007 2:49 am

That wouldn't work shalimar, mainly because the entire point of events is to pretty up the code and speed it up by removing the need for those kind of #IF statements. There aren't any "other events", just a series of Prompt events. In fact, it'd probably be even more ugly than simply #if-ing and executing the code without any events at all, since you'd end up with something like this:

#trig {(%d)/(%d)h (%d)/(%d)m} {#raise Prompt %1 %2 %3 %4;#if (@MaxTrack) {#raise Prompt1 %1 %2 %3 %4}}

and so on. The way around this that I use is to create each event in its own class, which is disabled and enabled as it's used. Since events like this are often part of some modular script that will have other settings associated with it, it'll be in a separate class with those settings anyway.