mIRC Home    About    Download    Register    News    Help

Print Thread
#132823 14/10/05 06:09 AM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
OP Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Seriously, there needs to be a way to RESUME normal processing of an EVENT with modified data rather than just halting it entirely. For example, you have two ON INPUT events. If they both modify the data (output string) yet are unawear of each others existance they both willl process the input string independantly and then both send out there own independant data (i.e /msg <target> <string>). For example you load both a nick completer and a control code stripper. The two scripts are independent of each other and can not intercept, modify, then resume so that the modify data is not passed on to the next script or back to mIRC's internal handeling of the execution.

The idea is NOT to halt and override the processing of an event, but rather to just modify and then passing it on to be executed internally by mIRC or by another script with the same event handle.

Yeah I know ways around this (using a SIGNAL event and a global variable to store the data) but obviously this will only work if the script has been coded speficially to handle that.

Most of the time I do not want to halt the execution of mIRC's internal event handleing but I do need to modify the data. Why would I want to skip the internal handling of an event unless I absolutely wanted to.

Of course I don't think I've ever seen anyone else ask for something like this, which I find strange cuz I've been wanting something like this for years and years now.


Beware of MeStinkBAD! He knows more than he actually does!
#132824 14/10/05 06:59 AM
Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Control stripping can be done but in mirc options itself, or with a simple $strip(), there is no need for a whole event for code stripping.

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

alias stripcodealias {
; code in here, set result to local var %result or something
RETURN %result
}
alias somethingelse {
; code in here, set result to local var %result or something
RETURN %result
}

on *:input:*:{
var %out = $stripcodealias($1-)
var %out = $somethingelse(%out)
msg $target %out
}

OR simply something like

on *:input:*:{
msg $target $somethingelse($stripcodealias($1-))
}

Well im sure you get the idea. This same concept is true for most all of mirc scripting. If i have misunderstood you post i apologise and please clarify.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
#132825 14/10/05 08:15 AM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
OP Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Quote:
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
Code:
ON *:SIGNAL:INPUT: { 
  ;code
  set %string &lt;result&gt;
}


EVENT HANDLER #2
Code:
ON *:SIGNAL:INPUT: { 
  ;code
  set %string &lt;result&gt;
}


TRIGGER EVENT:
Code:
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.


Beware of MeStinkBAD! He knows more than he actually does!
#132826 14/10/05 11:52 AM
Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Indeed, although i still think scripts that manipulate events and output should be ran through aliases in this manner as it would allow people to disabled the event trigger and make there own event combining scripts. And its easy enough to add an if to only process each alias call if it exists. Personally i think changing the control of events in this way would do more harm than good.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
#132827 14/10/05 07:27 PM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
I beleive the current methodology of not allowing modified data to be created, is a deliberate act rather than just what happened. If a script is allowed to make changes to what essentially is not data from the real source , then how can the next script be expected to process that info in a reliable method.
ex of your way...
Script1 highlights your nick said by anyone else in a rainbow of colors & like this [N][l][C][K]
Script2 kicks anyone out who uses color hes kicked becuase you colored it
Script3 logs all input from channels to a file its logged in color and [ ]'s
Script4 places all text said with your nick in into a seperate window this fails becuase nick != [N][l][C][K]

As for scripts not knowing somethings already dealt with this event, well thats just scriptors ignorance in not knwoing of the $halted identifier.

To maintain compatability between existing scripts and wanting to have new scripts that could have the ability to alter the original contents I would suggest a new command and identifier
/ALTPRAM & $ALTPRAM
/ALTPRAM works the same as RETURN works in that the script exits, however it loads $ALTPRAM with what ever you want the new parameters to be.
Any following scripts can compare $1- to $ALTPRAM, and deal with them as they wish, the final default handler can be set in options to use either $1- or $ALTPRAM as its parameters.

There may be a few fiddly bits still to work out with that, but i wouldnt see any large problems, all existing scripts well just chug along using $1-, new ones can do what they need to.


Link Copied to Clipboard