Forums Scripts & Popups Order of output with on INPUT

I have a script that I wrote that handles stats in my channel. I set it up so that it can display stats from a user's request and from requesting them for the client with the script (using on INPUT). It works great. However, if I do something like this from the client with the script:

!channelstats

It shows up as:


Notice that the text I typed appeared after the msg lines displayed the stats to the channel. It appears this way on the client with the script and for everyone else in the channel. I assume on INPUT is handling the code before displaying the text you typed in case you want to halt it, but it's a little strange.

It's been like this for a long time, but wasn't always like this. A new mIRC version changed it to appear after the msg lines, but now I forget what version it was... probably something around 6.03 or so.

Anyhow, I know I could do a workaround where I msg the channel with !channelstats followed by the msg's for the stats and then halt my text. It will appear first that way, but I shouldn't have to do it like that. Does anyone know why it does this or have a suggestion on how to prevent it from doing that?

It does that because that's the order in which you're telling mIRC things should happen. on INPUT always triggers before the text is sent, so sending anything else before the event ends will result in that appearing first. I don't know anything about it not working like that in the past, but then I don't use on INPUT very often. As you said, it's an extremely easy fix for your code so there's really not an issue.

don't know which you find easier but if you'd prefer not to have to haltdef etc. you could always put those messages on a 0 delay timer so they're sent just after the event ends (and the original text is sent)

Good point. Wasn't thinking of a timer.

Ok, that works well. However, is there some reason why the timers work in reverse?

In the on INPUT event,

.timer 1 0 msg $chan this
.timer 1 0 msg $chan that

Will display:

that
this

yeah if i remember right there was a big discussion about the order in which timers with the same delay are executed, which is why the -d switch was added



a combination of the h and d switches will do the trick

Hmm. Does that mean that is buggy, since it doesn't match what is stated in the helpfile:
?

Or is that to do with how $* is being handled??

yeah that's what i thought when i saw it, but if you look at:



that retains the order so it seems -d doesn't handle tiny delays well unless you use -h ;S

I'm still not sure that it's not a bug (note the double negative

I don't pretend to know what the implementation of the timers might be, but I guess getting the 'expected' behaviour is more difficult than I'm imagining

As long as I can force the expected behavior, I'm happy. Though, it would be nice to have the timers go off in the right order to begin with.

As someone mentioned above, Khaled did "fix" the timer order bug, but in doing so, ALL timers became much slower in reacting. I believe it was decided that the order of execution of the timers wasn't absolutely important for most cases, so the mandatory order was removed, but the -d switch was added to enable the high importance orders to be maintained when necessary.

-genius_at_work

I still don't see why timers are being used at all. The easiest and most effective solution here was the addition of two lines:

As I stated, that was an option, but I was looking for another method. I didn't want to halt my normal input text just for that.

The haltdef would obviously go in the same conditional block that checked for the presence of the "!chanstats" command. It wouldn't effect any other input. But hey, whatever works for you.

I check a lot of commands... adding that to every command I might type would increase the length of the script more than I'd like.