This simply isn't possible with $input:

//echo -a $iif($input(hello, e) == $false, NO INPUT, INPUT)

Type $false in that box and press OK and watch it tell you you have NO INPUT. The same would happen for $yes/$no. That would be just as much a bug as the one you're claiming exists. Returning $no, $cancel and/or $false would break $input for more inputs than it is currently "broken" for, which is worse.

There's really no way to handle the third case when all mIRC can return is "data" or "no data", except to ignore it. You really shouldn't need to care about the cancel situation anyway-- an empty editbox should be just as much a "cancel" action as Cancel. if you accept the user inputting empty data as actual data then your UI sucks. If you're trying to implement the ability for a user to "clear" a variable then you should have a separate "clear" or "delete" button in your UI.

This is also not a bug because the behaviour is described word for word in the help file:
Originally Posted By: mirc.hlp
If there is an input editbox, the ok/yes buttons always return the contents of the editbox.

It seems quite intentional to me, for a good reason.

Of course, if you *need* the Cancel button and don't like what I said above, make a dialog. $input is too simplistic to reliably handle a situation like this.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"