Tab Order

[Rackle]

I've Wikied a code snippet to provide Tab and Shift+Tab navigation through a list of widgets. Hopefully that can be useful to others.

There is a problem with the caret (cursor within Editbox and MultilineEditbox) when clicking on the title bar of a FrameWindow or a widget not within a widget not included within the tab order; the focus remains on the appropriate widget but the caret disappears. I have not been able to figure this out.

[scriptkid]

Excellent! I'll try to incorporate your code tomorrow to see it in action

Thanks!

[CrazyEddie]

Hi Rackle,

I also have not actually tested it out as yet, but it sounds great. Nice work

CE.

[Rackle]

Made compatible with CEGUI v0.5 release

TODO: Replace the secondary window/dialog with a TabControl to show how to navigate each page of a TabControl (not that it's hard to figure out how to do that from the TabNavigation.h header).

Would also be nice to figure out a way to navigate from one window/dialog to the other. The call to setParent() can be used to maintain a list of such windows/dialogs. However alt-tab and shift-alt-tab are reserved hotkeys under Microsoft Windows and I do not want to mess with those. The hotkeys to activate the next or previous window/dialog could be user-configurable, such as ctrl-tab and shift-ctrl-tab.

[daves]

Rackle,
I dropped this code into my project. It compiled/built without modification. I then instantiated a TabNavigation object within one of my dialogs, set the parent window, added a handful of widgets, and voila I have tab navigation working.

You da man.

Now a couple of questions:
1] Is there any intent to pull a class such as this into the CEGUI baseline? It seems like something such as this should be.
2] Looking at the code you reference macros that you call: HACKED_FOCUS_LOSS, HACKED_FOCUS_GAIN. These macros seem to do exactly what I would hope that they do "they highlight the window that has the focus based on the tab control". Why are these "HACKED" from your perspective? I'm assuming that this is because you feel there is a better way to handle focus. Please elaborate.

Thanks for this class. I will continue to use it.

[Rackle]

The better way would be for the scheme to have different imagery for this state. For example a pushbutton should display a dotted square around the text or image. That same dotted square should be displayed around an image, around the text of a checkbox or radio button.

As far as being within Cegui itself well it sort of is, from the Wiki. Maybe there could be an add-on folder that contains these various features with the download.

[daves]

I see. Thanks for that explanation.

[Protagonist]

Hi there. This looks very useful.
I want fast user entry for a series of input boxes, with OK buttons.
Would it be possible to use this code so that when an entry box has focus, hiting return will be the same as pressing the OK button used submit the entry, and move focus to the next entry box? Bassicaly, so the user can type, press enter, type in the next box, press enter, and so on.
Any tips on how to go about doing that would be much appreciated.

[Rackle]

I've been working for a database company for over ten years. A major part of my job is creating new windows to input data. At first we validated the data when the user left a field, preventing wrong data from being entered. Through user feedback we've changed our approach to validate when the user presses the ok/save button. If there's an error we display an error message and put the focus back into the field. With this approach users can enter the fields in any order they whish.

Back to your question. Each widget listens for a tab or shift-tab keyboard event, which calls the _onCharacterKey() function. You could check for the enter key (both on the main and the numeric keypads). At that time you could call your validation function and if you find that everything's ok then you "save" that data and inject a tab keyboard event, to activate the widget navigation code and move to the next widget.

[Protagonist]

Thanks. I was wodering, how would you know which widget the current entry was made for, when OK was pressed? Would I have to check for all widgets if it was active, or, can I retrieve a current active widget from cegui?

[scriptkid]

I think that Rackle suggests that you check for Ok in each widget. So each widget listens to character input. You know which widget you're in through the 'event.window' member. That window is then also automatically the active/focussed window when speaking about keyboard input.

HTH.

[Rackle]

Yeah, what scriptkid said. Within the _onCharacterKey() function you know which editbox you are in.

The way I pictured your .layout is multiple rows each containing an editbox and an Ok pushbutton on its right. Maybe that's not what you meant, maybe you meant that you have 10 editboxes and one Ok button? If that's the case then have a look at DialogSystem. That's designed to facilitate user entry.

[Protagonist]

No you thought right, I meant sever ediboxes with an OK pushbuttons each. I'll try this soon and let you know how I got on. Thanks