Forums Feature Suggestions New switches for $input

1. Extend 'b' to 'b[N]' which allows optionally specifying the number of seconds to disable the buttons, with the default for 'b' remaining 1 second. A reasonable max seconds could be enforced if that would be appropriate. b0 would clear the keyboard input buffer as 'b' currently does, without any delay.

2. New switch 'F[N]' or similar which allows you to set Focus for which button activates when the spacebar or <enter> is pressed. 'F' or 'F0' would cause none of the buttons to have the focus, 'F1' and 'F2' would be 1st and 2nd buttons respectively. Any N greater than the number of visible buttons would be same as 'F0'. If is easier to have the N be required with 'F', that's fine.

These would allow making sure the user has more than 1 second to read an important prompt message before responding.
Also allows changing the default action away from the 1st button
Also allows requires something more than spacebar or <enter> to trigger a reply
Also allows ignoring the existing contents of the keyboard input buffer without a delay.

sendkeys shows that in the absence of the 'b' switch, $input currently behaves like clicking on YES when there's a spacebar or <enter> already in the keyboard buffer.



'b5' would allow 5 seconds for reading the prompt before accepting keyboard or mouse input. 'F0' would move the focus away from any of the buttons, requiring a <tab> before the spacebar or <enter> would activate a button.

$input continuation

#3. allow kN to be k0 with a zero seconds delay, instead of ignoring the -k switch.

One of the use-cases for -kN is for a script which otherwise freezes mIRC but you still want occasional screen updates without the extra 1 seconds pause from -k1.

//var %stop $ctime + 30 | while ($ctime < %stop) { var %tmp $ctime | while (%tmp == $ctime) { noop } | echo -a $asctime secs left $calc(%stop - $ctime) | if (*0 iswm %tmp) echo noop $input(label,ok0) %tmp }

The above use of $input does restore the screen update if you've alt-tab'ed away/back, but it also interrupts the script for an extra second. And if I try to avoid the 1 seconds delay, the k switch is ignored, and it instead presents the dialog prompt that won't go away without input.

#1a one of the benefits extending 'b' to be 'bN' is that it would then play friendlier with the kN switch, where you can present a dialog with plenty of time to read the message before allowing the keyboard input. As things stand now, the minimum effective value for kN when used with b-without-bN is k2, because bk1 never accepts input. The example below never returns $yes even if you hold down the Y key.

//var %stop $ctime + 10 | while ($ctime < %stop) { var %tmp $ctime | while (%tmp == $ctime) { noop } | echo -a $asctime secs left $calc(%stop - $ctime) $input(label,nvbk1) }

My proposal is that b0k0 would flash the screen long enough to permit timers to execute and to allow responses that prevents a script from causing you to be timed-off the network, but there would not be an unneccessary 1-seconds delay. b5k15 would have a 5 seconds wait to make sure the user has time to read the message before allowing input, then gives them an additional 10 seconds to reply before the dialog goes away.

This use of $input would minimize delays, and make it easier for a script to avoid freezing mIRC off the network, without shifting it to a timer where &binvar and %tempvar's would need to be saved and restored, and it wouldn't be guaranteed that the script would be able to resume in the same context as before.

I guess I need to post additional on this because someone in channel got the wrong idea from what I said in #1. For the 1st snippet, if you change the 30 seconds to 630, and change from the k0 that's ignored into the k1 that will put a 1 seconds pause into the script, this will allow a WHILE loop to run for 10 minutes without having the screen display being frozen, and without the server doing a ping timeout on me. I was hoping to be able to change the k1 to k0 so the pause could be shortened to the minimum time needed to update the screen and avoid ping timeouts. For #1 I'm not needing to read any message in the input window, and I'm not expecting to input anything, except possibly a keypress that would cause the loop to exit.