Previous Input Values Returned on [Enter] with Single Input Control Only

[matthes-b]

I am observing the following behavior, which I think might be a bug:

1. Clicking 'Accept' when there are multiple input controls works fine.
2. Clicking 'Accept' when there is a single input control works fine.
3. Pressing [Enter] when there are multiple input controls works fine.
4. BUT: when pressing [Enter] when there is only a single input control in the dialog, then the dialog appears to always return the value from the previous dialog run, not the newly entered value.

I am currently trying to track this down some more.

[matthes-b]

I noted inputbox.html:34
<div id="app" **v-on:keyup.enter="accept"** ...>
seems to be doubling things up, resulting in type_convert being called twice.

The binding of KEY_RETURN in globalKeyup() is enough.

[matthes-b]

The bug noted at the top seems to be caused by a default "onSubmit" action reloading the dialog when pressing [Enter] when there is only a single input control in the dialog.

Adding the following to inputbox.html appears to fix this problem:
<div id="app" v-on:submit.prevent="onSubmit"

[thomthom]

Adding the following to inputbox.html appears to fix this problem:

Care to do Pull Request with that?

[matthes-b]

Ok, I might have figured it out. Pull request here.

[DanRathbun]

Just a note to say that the binding of ENTER to accept is likely to go away (at least IMO in actual use by devs.)

I added a Textarea control in my edition and ENTER is needed to remain as an edit newline feature for text input.
Users also sometimes expect that ENTER will advance to the next control in the form.

So I never really liked setting ENTER to fire the accept button because for normal dialogs, this does not happen unless the button has the focus. Firing a button when an edit control has focus is seems abnormal.

EDIT: I do notice that the UI::inputbox leaves the buttons with focus even when editing input fields.

[matthes-b]

At this moment the issue of course becomes a user interface design question, no longer a technical one...

IMO operating input forms and dialogs - whether they have single or multiple fields - would still be fastest and most traditional by using [Tab] to advance to the next field and [Enter] to submit the whole dialog (as is the case in the old UI.inputbox).

I certainly would not want to touch the mouse for anything in a simple dialog such as this (I also use keyboard entirely for dropdown boxes etc) and I use UI.inputbox very heavily to edit components, as this can be made to be much faster and more responsive than say the Component Options dialog.

Admittedly, as soon as multi-line text boxes come into play then things change, and a decision has to be made whether to use [Enter] for line breaks in text areas or whether to use a modifier [Alt-Enter] for line breaks as is for example done inside Excel cells.

As said, it is now more of a design decision, and if it is not a goal of the HTMLDialog inputbox to mimic the old inputbox 100%, then that is okay.

I do understand I have a bit of a traditional view here and even Windows itself is now often moving away from this, or at least simply neglecting keyboard-only operability.

[DanRathbun]

At this moment the issue of course becomes a user interface design question, no longer a technical one...

Staying on the technical point for a moment, my testing shows the your PR #9 has at least solved the issue for forms with a single textbox control.

It was an aside to the issue. Just something to think on.

Admittedly, as soon as multi-line text boxes come into play then things change, and a decision has to be made whether to use [Enter] for line breaks in text areas or whether to use a modifier [Alt-Enter] for line breaks as is for example done inside Excel cells.

We also have the alternative SHIFT+ENTER for soft breaks as a convention.

As said, it is now more of a design decision, and if it is not a goal of the HTMLDialog inputbox to mimic the old inputbox 100%, then that is okay.

Well, I will guess that it probably is a goal for this example repository to mimic UI.inputbox.

Most likely any new nifty features would need to be added to forked editions that would be in a custom library namespace.

IMO operating input forms and dialogs - whether they have single or multiple fields - would still be fastest and most traditional by using [Tab] to advance to the next field and [Enter] to submit the whole dialog (as is the case in the old UI.inputbox).

There is series of complaints with the Mac OSX users about dialogs and inspectors doing unintended things with respect to textbox controls. I'll need to review those. I "think" it had to do with what the users intended to use as the key to signal end of input. Complaints centered mainly on the Entity Info panel, but also the Scenes and Tags panels.

An example is when I add a tag (layer) it automatically enters the tag name edit field and after typing a name, the ENTER key finishes input and the tag list is reordered to put the new tag in it's collated position. And yes, using TAB instead also works (on Windows at least.)

Anyway any further discussion can be in a new issue on textareas if needed. But for this repo likely the textarea controls will have their own key event handlers that would trap ENTER if it's part of a soft return.

[matthes-b]

Well, I will guess that it probably is a goal for this example repository to mimic UI.inputbox.

If that is the case then I would have this next issue to discuss:

As you noted earlier the old UI.inputbox seems to leave the focus on the OK/Cancel buttons in a way that means [Enter] will always fire/submit the whole dialog.

That means in old UI.inputbox with a single Dropdown control with multiple options I can use either the cursor keys or [Alt-Up/Down] to choose an option and then press [Enter] to submit the dialog.

In new HtmlUI.inputbox with focus on a Dropdown control I can also use cursor keys or [Alt-Up/Down] to choose an option, but I cannot press [Enter] to submit the dialog. The focus is on the Dropdown and [Enter] will instead also drop down the list on the control to allow the user to choose an option.

I can of course [Tab] out of the control first and then press [Enter], but this is two key presses instead of one every time I run the dialog and the old way (i.e. classic Windows style?) was a bit faster. So - not a big issue, but if the goal was to mimic the old dialog completely then [Enter] on a Dropdown should also fire the whole dialog.

I might try to get this going in my code first to see if it has any other implications...

[DanRathbun]

In new HtmlUI.inputbox with focus on a Dropdown control I can also use cursor keys or [Alt-Up/Down] to choose an option, but I cannot press [Enter] to submit the dialog. The focus is on the Dropdown and [Enter] will instead also drop down the list on the control to allow the user to choose an option.

Yes, I also noticed this yesterday. Differences in default behavior of native OS vs HTML controls I suppose.

Note that @thomthom used the word "similar" in the docstrings for the HtmlUI code and README.

Also, the old UI.inputbox is bugged with respect to TAB order and initial control focus.

That means in old UI.inputbox with a single Dropdown control with multiple options I can use either the cursor keys or [Alt-Up/Down] to choose an option and then press [Enter] to submit the dialog.

Actually (in old UI.inputbox) when I press ALT+Down to expand the focused dropdown then arrows to select, if I hit ENTER (whilst the dropdown is still expanded) it just collapses the control with the current selection as the value. I need to press ENTER a 2nd time to close the inputbox.

If the cancel button has the focus then ENTER gets us false returned and no array of input values.

ENTER is only (supposed to be) a guaranteed acceptance of input when any of the inputs have focus. (I think the dropdown expansion variance is a quirk. Some might say a bug.)

[matthes-b]

Also, the old UI.inputbox is bugged with respect to TAB order and initial control focus.

From what I can see, in the old inputbox the focus is usually on the first control, and I can TAB through all controls in order, then to [Ok], then to [Cancel], which seems correct to me.

if I hit ENTER (whilst the dropdown is still expanded) it just collapses the control with the current selection as the value. I need to press ENTER a 2nd time to close the inputbox.

Yes, ENTER from the expanded dropdown first collapses the list, which is fine. But having ENTER on the input itself submit the dialog is still quicker than first tabbing out to the [Ok] button.

Other use cases are: cursor UP/DOWN + ENTER on the dropdown, and I also like typing the starting letter of an option in long lists to jump to that option, then cursor keys, then enter. Not quite a full incremental search - but fairly standard, and works in both old and new inputbox.

[matthes-b]

So, when I put v-on:keydown.enter="accept" back into inputbox.html:34 (I had taken this out in pull request #9) then it looks like [Enter] on a dropdown will again submit the whole dialog (rather than expanding the dropdown) which is the old inputbox behaviour. I will be testing this for a while.

I had taken the global keydown.enter out of <div id="app"> because I was seeing type_convert() being called twice, but I think that was because of the default v-on.submit, which is now being prevented.

[DanRathbun]

From what I can see, in the old inputbox the focus is usually on the first control, ...

It is on the last control AFAIK. It should be on the first control if it worked like all other dialogs throughout history. ;)