On to the main subject, i think the current behavior is preferable. The issue here, imo, is not how mirc handles events, but rather how scripters make unfounded assumption and write script that are not entirely compatible with others.
A simple solution is to NOT use multiple events for something like this, rather use one event that calls aliases. fex
You assume we are working with one script. Written by one author. I'm talking about two seperate "addons" which could be written by anyone. mIRC allows you to load more than one script. If it couldn't this would not be a problem and your code would be just fine.
Also, even now, you wouldn't want to use aliases. If one script containing one of your aliases were removed, it would completely break the execution of code, because the identifier to this missing alias would return nothing ($null) which would mean nothing would be sent to server.
You would want to use something more like this...
Event Handler #1
ON *:SIGNAL:INPUT: {
;code
set %string <result>
}
EVENT HANDLER #2
ON *:SIGNAL:INPUT: {
;code
set %string <result>
}
TRIGGER EVENT:
ON *:INPUT:*: {
SET %string $1-
/SIGNAL -n INPUT
/IF $left(%string,1) == /) {
%string
}
else {
/msg $target %string
}
halt
}
The above example is, atm, the closest solution to addressing my problem. But in order for it too work the /SIGNAL INPUT event must be triggered. And the only way to sure would be to have the trigger event in the same script. Which would ultimately cause the same problem if multiple scripts with their own INPUT handlers where loaded.
And, alas, ON SIGNAL events do not allow mIRC to continue it's own internal handeling of the event.
Does this clarify what I'm asking? I hope so.