User input

[holatuwol]

First off, the event is fired when the main KoLmafia window gains focus.

Or alternatively, have ASH create a window listener, attach the listener to whatever window is holding the CLI (and have the listener automatically detach itself as soon as it's run), and ASH will block while polling the listener until something's been entered and return a value once it sees something.

That might work.

That leaves us with the second, less obvious problem. Every dialog box has a cancel option. It's pretty obvious how it should be handled in a user_confirm, but how should this be handled in a user_input? Return something like $item[none]?

Once I'm done butchering chat (yeah, I'm still working on it sporadically), I'll try reworking KoLmafia to use this strategy internally for all dialog boxes. If everything checks out, I'll consider adding user_input if you guys come up with your preference on the second issue.

 

[Catch-22]

For me it doesn't matter what Cancel returns, provided it returns the same value each time.

I'd probably say a Null is best suited, but I don't know how well it fits in with the rest of KoLmafia.

 

[Bale]

As long as it consistently returns a null like an empty string or $item[none], any competent script can test for that possibility.

 

[Catch-22]

As long as it consistently returns a null like an empty string or $item[none], any competent script can test for that possibility.

Yep, but anyone who has worked in SQL will tell you there's a big difference between an empty string and NULL

Or alternatively, have ASH create a window listener, attach the listener to whatever window is holding the CLI (and have the listener automatically detach itself as soon as it's run), and ASH will block while polling the listener until something's been entered and return a value once it sees something.

That might work.

This might be a way to enforce input, but would it solve the "rogue dialogue" problem?

 

[Bale]

Yep, but anyone who has worked in SQL will tell you there's a big difference between an empty string and NULL

Unless there is a $string[none], all ash can use for that is "". Is $string[none] valid?

 

[holatuwol]

This might be a way to enforce input, but would it solve the "rogue dialogue" problem?

In theory, yes, because no dialog will be displayed until the listener fires when a window receives focus. In practice, we'll have to see.

Unless there is a $string[none], all ash can use for that is "". Is $string[none] valid?

I don't think it's valid. You'll have to check against "" when you're prompting for a string.

 

[zarqon]

Canceling the dialog should cause an abort state. A value of $type[none] is basically useless, and empty strings are useful for saving time by using default values (most of my scripts that require strings perform some default action if the string is empty). If a user cancels the dialog rather than selecting a value, more than likely they want to stop the script, not supply an indirect value to the script which they are almost certainly unaware of.

I'm fine with the option existing for capturing results to prevent an abort, but I'm not happy with the value for canceled string dialogs being "". I use empty strings as valid input all the time.

 

[Catch-22]

In theory, yes, because no dialog will be displayed until the listener fires when a window receives focus. In practice, we'll have to see.

Ah yes, I misunderstood what your event was listening for.

I don't think it's valid. You'll have to check against "" when you're prompting for a string.

Aww.. Can't you implement null in ASH?

The little programmer inside me just thinks there should be a distinction between a user hitting "Cancel" and the user just not entering any data.

Edit:

Yeah, I just read zarqon's post, I completely agree with him. If there's no way to distinguish between empty string and a Cancel, I would rather the script abort.

Either that, or have the ability to specify a function as an optional secondary argument. So that if the user clicks cancel, the function is called (which may itself just abort).

 

[jasonharper]

An abort state from a dialog would be pointless; you'd presumably always use the return value from a hypothetical prompt function, and therefore would always capture any error that occurred - and would still need some way of distinguishing the canceled value from an actual value. It would probably just have to exit the script on cancellation.

(And $string[none] is perfectly valid; it's the same value as "none", so rather useless here. A practical cancel value for strings, distinguishable from anything the user could reasonably type, would have to be something like "\u0000".)

 

[Catch-22]

Yes, you're right. The error handling would be different though.

Unexpected input from a prompt could simply prompt the user again with something like:

"Sorry, please enter numeric only:"

Handling of Cancel must be different in this case, because an empty string might also be considered input, be it valid or otherwise. A Cancel shouldn't be considered as input at all.

Perhaps a non-typed character would suffice though.