String picker search field

[NQNStudios]

It will fit at the top of the dialog, there's some blank space by the dialog picture. You'll type into it and click a Search button. It'll do a case-insensitive search of the strings starting from the current page. It'll set a highlight color on matching strings. If there are none on the current page or you hit the button twice, it'll proceed to the next page with a match. It can have a little label that might tell you 'No matches' or 'Reached end, looping'

[NQNStudios]

@CelticMinstrel Here's how it looks:

One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker. And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers?

For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key.

[CelticMinstrel]

One thing that's troublesome is you expect 'Enter' to run the search you've typed in, but it clicks OK instead. But I'm not so sure making the search button the default would be good to do in every string picker.

Hmm, yeah, this design is a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having no field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not.

But, there are other options that come to mind.

1. Remove the text field and "reverse" toggle - just have a search button. That brings up a separate search dialog where you enter in your query, possibly select reverse, and click OK. The query could still be shown as static text in the dialog. There are still a few issues, but that's similar to how RPGMaker handles search.

2. The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK.

Also, the button should have a keyboard shortcut of Ctrl+F. I also think the status text just below the field should be in a slightly smaller font size.

And whether it (the search feature) should be made optional per dialog type. Maybe it could automatically appear for multipage pickers?

It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog.

For the 'give item' debug action picker shown here what I'd like is for the search to be Enter and the "OK" button to say "Give", with g as its key.

Changing the label on the button is as easy as choiceDlog->getControl("done").setText("whatever"). Not sure if changing the key is equally easy.

[NQNStudios]

Hmm, yeah, this design is a bit troublesome. From what I recall, the notion of "focus" in dialogxml is very basic, and there is no concept of having no field focused. If that concept existed, my expectation would be to hit search if the field has focus and hit OK if it does not.

I was thinking that a kludgy concept of 'focus' could be added to this specific dialog, by manually toggling the dialog's default button in response to:

• Selecting an LED -> make the OK button default
• Typing in the search field -> search button becomes default
• clicking on the search field -> search button
• clicking the search button -> search button
• toggling the reverse led -> search button

[NQNStudios]

It seems like it would be really hard to generalize it down to something that can be used in any dialog. The specific logic of the search in particular depends on the dialog.

I meant multipage string pickers.

[NQNStudios]

The input field is invisible until you press Search. Once it's visible, enter hits Search instead of OK. Perhaps Ctrl+Enter hits OK.

I went with this solution.