Forums Bug Reports $input and 'e' option

$input doesn't return $cancel/$ok or $yes/$no when used with the 'e' option :
It even returns $null if you enter something in the editbox and hit cancel/no

from the help file:



yes, i agree it defeats the purpose of there being a 'v' option to a slight extent, but what would be the point of the editbox otherwise? or are you suggesting it should return $no/$cancel and editbox contents when yes/ok is clicked? i think you have to accept that 'e' supersedes 'v' and that the two options are largely incompatible.

Well yeah but that's unfortunate because as you said it defeats the purpose, ideally $input should always return the button pressed and if an editbox's was used, $! would return that information.
The help file says that by default (ie. not when using the 'v' option) it returns the editbox's content so when 'v' is used the button should be returned... the fact that $! also returns the $input value rather than the editbox's content is just another bug (according to the help file).
Now it's probably not going to be fixed because that would break script however, adding a new switch to fix the problem doesn't seem to be the good way around this, especially since the new switch would do what 'v' is supposed to do.
I think it should be fixed to work as expected even if it can break script because if a script fails with this, it only means it uses a behavior that's not defined in the help file.

Another bugs:
$input(a,ov) return $ok but $input(a,onv) return $yes even if only the ok button is displayed.
similary, $input(a,rnv) returns $retry if you press "yes".

As a note, with 'r', $retry can be returned, which is not documented and isn't even known as an undocumented identifier.

I guess that would work since you could check for $cancel/$no if you wanted to handle that, and use the value returned otherwise (you can't have a "ok" button and a "yes" button at the same time afaik and the editbox's content is only returned if yes/ok was pressed)

Actually, "by default" refers to $true/$null, not the editbox content. They are in the same "paragraph", but the "by default" only relates to the sentence it is in.

I suppose you want a user to be able to press OK with a blank box and treat that differently than if they hit cancel?

Well, that's what I want the help file to mean and if the default means "no editbox is used", $input can't even return $null
Basically yes, but I'm rather reporting a lack of functionnality with $input in these cases:

I wasn't disagreeing about the lack of a way to see what was pressed in those instances. I was just wondering the need for it. In most cases, an empty editbox is going to be treated in the same way as cancel, so there wouldn't be a need to do anything besides check if it's $null. But if you need a $null + OK to be treated differently than Cancel, then it would definitely help to have the functionality added.

As to the help file, you're right about $null. Maybe it is meant to say what you "want" it to say rather than what it appears to say to me. At this point, I'm not sure anymore what it is supposed to mean. It would help for that to be clarified along with adding in outputs for "v". Might as well do both at the same time.

The command is inherently ambiguous. There's really no way for mIRC to return both the results and the button value in one consistent response unless it *always* returned the form: "$ok TEXT"-- but that would break backwards compat. Another way would be to introduce some $inputcode identifier similar to $readn which returns the last status code for an $input separately. Then you could do //noop $input(a,e) | echo -a $inputcode -- this would be backwards compatible, but slightly more awkward.

I'm not sure how mIRC could change the behaviour here. If mIRC returned "$cancel" for an empty editbox, then you would still have an ambiguity in the case where the user actually *TYPED* "$cancel":

//echo -a $input(a,e) and type "$cancel" and hit OK.

Basically, if 'e' is used, it has to *always* return the editbox contents. This is a special case, and though admittedly not documented in the help file, it's definitely there by design (I remember discussions about this specific behaviour somewhere) and probably isn't considered a bug. There's simply no consistent way around this given the API. The only way to change this is to actually add new functionality via one of the options listed above-- but the behaviour in the case you described would lead to more bugs and would simply not work.

i think the most sensible way to overcome the problem of ambiguity is to introduce a switch that causes $input() to behave as it should: return a value indicating which button was pressed, and fill $! with the text in the editbox, if any.

for example, if we call our switch 'x':

Avoid $input and use custom dialogs.... that's all I gotta say.