Forums Bug Reports Timer bug

I have this timer:

timerwake -o 6:30 1 1 splay C:\cripta_D\mirc603\sounds\nightwish\wishmaster.mid

but if an input request is active by the time the timer should trigger nothing happens. please fix. I got late to work twice already :-P

Buy an alarm clock
Maybe it did work but you were sound asleep?

i try that kode.. and it works!!!

weird... well, for some reason it's the second time the timer doesn't trigger. And I didn't fell asleep. The audio system connected to my PC can wake up the whole neighborhood and everything was set up quite loud

I think its a bug try this:
//echo $$?="test" | timer 1 3 test
nothing happen when the input is open.

How is that a bug as the timer doesn't start till the script finishes executing . while the dialog is open the script is halted.

oh yeah my bad

code works find for me.



you are telling it to play the sound 1 second after 6:30 1 time. If you want it to play twice maybe try



I hope i didn'nt misunderstand the bug.

I don't know if I'd call this a bug, so much as "How mIRC Works."

Try this example, it should explain everything. (Type it in your status window)

//timerABC 1 1 echo -a ABC $!?!="erf?" | timerXYZ 1 2 echo -a XYZ

You will note that 2 timers are started at the same time. after one second, the first timer fires and a Yes/No prompt appears. one second later the second timer is suppose to fire but does not, because it's still waiting for you to select Yes/No.

It would appear that timer commands just have to wait for Input dialogs to go away before they can continue. This may be a bug, or an oversight, or by design... it's hard to tell.

Rule of thumb: Never allow an event to automatically display an Input dialog, especially if you are not around to take immediate action. Khaled put that warning message there for a reason, "$?: can't use in an event". You chose to disobey him by using a work-around. For this you must pay.

- Raccoon

mIRC script engine is single threaded ie. only one script can execute at time, so if input dialog is open one script is running, so the other can't start.

Well, that is true, but it isn't exactly the case... at least, it's partially the case.

You'll note that other events and aliases trigger perfectly fine in the background while an input dialog is visible. Only timers are effected by this. The other timers still count down happily, but the commands get stacked up waiting to be released. The reason the timers are getting stacked up is because the $input dialog was called by a timer, and they share the same thread--so to speak.

Other events don't have this problem, all other scripts execute fine without being held up.