Using /did -f on a tab control inside the init event results in weird behavior, the specified tab doesn't have the focus and is locked until you activate another tab:
dialog test {
size -1 -1 200 200
tab "", 1, 10 10 100 100
tab "", 2
button "", 3, 10 150 30 15
}
on *:dialog:test:init:0:{
echo -a init test
did -f test 2
}The first tab will be in focus instead of the second, you can't activate that second tab until you click inside the first one (on its "titlebar")
If you add a timer of 1 second then it will go to the tab you want.
If you add a timer of 1 second then it will go to the tab you want.
a 0 second delay would do the same without the pause, but that doesn't mean this isn't a bug :P
confirmed on Windows 7 Basic. looks as though mIRC is only half-activating the tab.
Another related problem, calling $input inside the init event will display the $input dialog before the custom dialog, again, a timer solve the problem..
For this one, if the problem isn't easy to solve, maybe $input could report an error (* $input: cannot use in an event) for consistency since calling a timer is the way to bypass this.
Edit: in fact it's not related to $input, the dialog window is just not visible until the init event is done, which looks like intentional
Using the -m switch for /timer will solve it so far, you won't notice it that there was a timer anyway.
/timer -m 1 1 did -f test 2
It's not really 0 seconds but it acts almost like it.
Using the -m switch for /timer will solve it so far, you won't notice it that there was a timer anyway.
/timer -m 1 1 did -f test 2
It's not really 0 seconds but it acts almost like it.
If you didn't know, you can just make a timer with an actual 0 second delay, like jaytea already hinted at.
I misunderstood something, just ignore my post. :p