mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#181358 22/07/07 10:56 AM
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
//echo -a $input(title,env,prompt,edit)
This returns edit/$null/$null
Should return: edit/$no/$cancel

So it returns $null for 2 buttons. I cannot find out if the no or the cancel button was pressed.

Read more here


Gamers.IRC - The best way to use mIRC
Joined: Apr 2007
Posts: 3
I
Self-satisified door
Offline
Self-satisified door
I
Joined: Apr 2007
Posts: 3
I think maybe you mean it should return $false instead of $no. but eitherway it is still a bug.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
The 'v' option makes mIRC return $yes, $no, $cancel, etc for input dialogs.

Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
It is all the same to me: $false, $no, $null, $cancel
BUT not the same thing for 2 buttons.


Gamers.IRC - The best way to use mIRC
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
Ok, I have a new similar problem:
//echo -a $input(text,, title)
returns $false or $true (works correct)
But
//echo -a $input(text,e, title)
again returns the same thing for 2 different buttons if you enter nothing in the box.
So I cannot konw if the ok or the cancel button was pressed.
Cancel should always return $false (or $cancel with v switch)

Please fix this!


Gamers.IRC - The best way to use mIRC
Joined: Dec 2005
Posts: 28
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Dec 2005
Posts: 28
I'd second that thread... please fix that... shouldn't be much effort.


Gamers.IRC team - gamersirc.net
#Gamers.IRC on QuakeNet (sometimes we're there).
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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"
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
Originally Posted By: argv0
This simply isn't possible with $input:

Oh, really? Well, I think this was the reason why I reported this bug.

Of course it would be possible when it gets fixed.
Returning $no, $cancel and/or $false would not break anything. In most cases $input is probably used like " if ($input(...)) { commands } "

Of course I could create a dialog. Of course I could create a workaround for everything and for every bug. And of course I can write my own scripts, IRC Clients and operating systems if I had enough time.

And yes, this is a bug, if it returns the same thing for 2 different buttons (because I don't need 2 buttons if they don't work in different ways). Moreover, you should read your helpfile more accurate: The sentence you quoted only relates to the ok/yes buttons if there is something in the editbox. But this is not the point, as you can see in my former posts.


Gamers.IRC - The best way to use mIRC
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
This was by design, for the reason that argv0 pointed out - if you type in $false, $cancel, and so on, in an editbox, that is in fact data and there's no way to tell the difference. I can't change that behaviour since it might break existing scripts, which is something I try to avoid. I can however add a new switch which behaves the way you are asking. I will add that to my to-do list for the next version.

Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
Is it already done?


Gamers.IRC - The best way to use mIRC
Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
it doesn't seem so, but in the mean time you can take advantage of the # identifier prefix which can be applied to $input() and lets you distinguish between an Ok press and a Cancel press:

Code:
//echo -ag #$input(Press Ok, e) - #$input(Press Cancel, e)


pressing Cancel results in a return value of $null, whereas pressing Ok will always return at least a # character.

of course, this presents a potential problem. the purpose of the # prefix (in this case and certain others) is to attach # to the return value of the identifier only if it isn't already prefixed with it. as such, you won't be able to distinguish between the user having typed 'abc' or '#abc'. with this in mind, you can decide whether or not it's appropriate for your intended purpose.


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
I am requesting to add a switch for this:

Code:
c (or something else) - Even in combination with an editbox the negative buttons (no/cancel) return $no, $cancel and not $null. $null is only replied for ok button if the editbox was empty.


Btw: I still don't understand why you say it works as intended.

Code:
v - return $ok, $yes, $no, $cancel for buttons.
...
By default, buttons return $true or $null, same as $?. If there is an input editbox, the ok/yes buttons always return the contents of the editbox.


I don't see why no/cancel should return $null for the ev switches. And who on this earth would type in $false, $cancel, and so on, in an editbox?

In fact it breaks scripts the way as it is at the moment. As a scripter you want to know if the user clicks on ok with an empty editbox of if he clicks on cancel.

Last edited by Chrisi; 01/01/14 07:55 PM.

Gamers.IRC - The best way to use mIRC
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Chrisi
Btw: I still don't understand why you say it works as intended. ... I don't see why no/cancel should return $null for the ev switches.


I explained clearly above, please re-read my post. The help file line that you quoted explicitly states the behavior in question: "If there is an input editbox, the ok/yes buttons always return the contents of the editbox."

Keyword: always.

$null is synonymous with the empty string in mIRC, in other words, they are equivalent representations:

//var %x = "" | echo -a $iif(%x == $null,$true,$false)

You are getting back the empty string from the input box, you don't actually get back "$null", but it is equivalent to $null, which is probably why you think that's what mIRC is returning. They are the same thing.

Originally Posted By: Chrisi
And who on this earth would type in $false, $cancel, and so on, in an editbox?


Anyone. Why are you even asking this? The fact that it's possible is the problem. It's not mIRC's job to place limitations on what people should and shouldn't be doing with the scripting language. A few very obvious examples: an input box may be used to help someone provide scriptable values, like "Please enter the auto-op condition to be evaluated when the user joins your channel", $false being "never".

Originally Posted By: Chrisi
In fact it breaks scripts the way as it is at the moment.


By definition, the existing behavior cannot "break" scripts, because it is the existing behavior. If you are using an $input with an editbox and are relying on this behavior your script is not "broken"-- it never worked in the first place. The help file tells you that it will never work, so there is no expectation mismatch here.

Originally Posted By: Chrisi
As a scripter you want to know if the user clicks on ok with an empty editbox of if he clicks on cancel.


Why is this being stated as fact? Not every script needs this information-- only ones that allow the empty string as a valid input, which is not every script.

-------

The bottom line is this: Khaled can't just break existing scripts, so a new switch would be necessary here regardless of whether you agree with the current behavior or not.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I support this, I had the same problem in the past.
The design should have allowed the 'v' switch to return the button that was clicked because we can access the editbox with $! anyway.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
No clue why this dude is arguing about the ok/yes buttons... My problem are the no/cancel buttons.

Btw: Even that wall of text is no reason for not improving the $input function. If you think some strange dudes enter $false, $cancel in the editbox... right, give me the switch.


Gamers.IRC - The best way to use mIRC
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I am "responding", not arguing, because you specifically stated that you still do not understand why $input is designed the way it is. Please re-read my response in the context of someone responding to the question you asked. Maybe then you will understand why I am "arguing" with you.

I also never said a single thing about ok/yes buttons. The only time those words appear in my post are from a quote of the help file that explains the behavior of $input that you are suggesting be changed. That quote is relevant because it explicitly states the expectation of $input with regard to use with editboxes. If ok/yes always return the editbox contents, it is not possible for any other button to have a different behavior, since it would not be possible to differentiate from the actual button being pressed. It requires a bit of mental extrapolation of the quote to reach this conclusion, but basically, you can read that help file quote and replace "the ok/yes buttons" with "all buttons". I would be in favor of suggesting to make that wording adjustment if it resolves your confusion.

For what it's worth, nobody said no to a switch, we're simply explaining the rationale that you didn't seem to comprehend. Please don't challenge existing design decisions and then act confused when they are explained. Thanks.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I think he was on the defensive because you said:
Quote:
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.
So first, his design sucks if he doesn't take $null as a cancel action, but then you give a very valid example that use $false NOT as a cancel action, so $null not taken as cancel = sucky, but $false not taken as cancel = fine, why would one not use $null as the same bool value as $false in your very valid example?
While I'm at it, you suggested to make a dialog in this case, but $input handles a number of feature that nobody is going to reimplement just because $input's design doesn't allow one to handle all situations.

Last edited by Wims; 13/01/14 02:42 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55

Code:
    var %newflags = $input($4 ( $+ $7 $+ ) flags $crlf $+ $init_lang(Qadmin,28), ev, $3 $+ : $init_lang(Qadmin,8), $8-)

This is an example how I want to use $input for editing a users Q-Flags in a quakenet channel.

$input has the options to have an editbox AND a cancel button. If the you click on OK, the new flags get applied. If the editbox is empty and you click ok, $null is returned and the flags get removed. But if you click on Cancel, $null is also replied and the flags get removed. However, the name of the button is "Cancel" and not "Nothing". So for me it is not working as intended.


Gamers.IRC - The best way to use mIRC
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
This feature has been added to the next version, where if you specify the 'f' switch in $input(), it will force the return of $no/$cancel for an editbox/combobox dialog.

Joined: Jun 2004
Posts: 55
C
Chrisi Offline OP
Babel fish
OP Offline
Babel fish
C
Joined: Jun 2004
Posts: 55
Agreed. Working with the 'f' switch since 7.33


Gamers.IRC - The best way to use mIRC
Page 1 of 2 1 2

Link Copied to Clipboard