I want to be able to let a user tab through a page in a specific way. In previews versions (Mendix 4) this was possible to setup. Simply by entering a number in the 'Tab index' from -1 till (lets say) 1000. This has been changed and now the function doesn't work the same way. "The tab index influences the order in which the end user navigates through the form using the tab key. By default tab indices are zero and the tab order is determined automatically by the client system. A value of minus one (-1) means that the widget will be skipped when tabbing through the form." In short, the field get's tabbed or not.
I've made the following picture to illustrate what I'm going for:
The standard way would be the black line. However, when a user adjusts the standard values (grey text boxes) and goes to one of them it should follow the red line to the next red one. That would give the tab index 1/3/7/8/2/4/5/6. With Mendix 4 you simply number them the way you want to. In Mendix 7 you can only tell if it's on or off, so now all the tab indexes are 0/-1/0/-1/-1/-1/0/0. But for those that do want to change the standard values, they have to select every box one by one because you can't tab to the next one.
How do I make this happen?
I just looked in a MX 7.18.1 project and there it is possible for me to enter a tab index number:
Tested this and looks like it's doing what you want.
Hope this helps.
Edit: Looked under the hood (in the HTML) and see that Mendix is not using the normal tabindex html attribute but their own focusindex. This is not an official attribute. I filled a support ticket because I'm curious why.
Update from Mendix R&D:
"Indeed we are using the custom attribute called
focusindex on widgets together with some special logic that handles the focus. But it is used together with
tabindex, not instead of it.
As our pages and widgets are dynamic by their nature we need something more flexible then just a flat tab order defined by
tabindex. We use so-called "nested" tab order. Additional custom property
focusindexsimply "marks" a DOM node as a container where
tabindex (or natural tab order) of underlying focus-able elements is "local".
We named it
focusindexto prevent the clash with
tabindex on naturally non focus-able elements. That makes them focus-able and we don't want that in this case.
Take a look at this simplified HTML structure:
<input id="textbox1" tabindex="1" /> <!-- tabindex: 1 set in the Modeler --> <div id="complexWidget1" focusindex="3"> <!-- tabindex: 3 set in the Modeler --> <input id="i1" tabindex="2"/> <!-- tabindices in this widget are rendered (hardcoded) by the widget developer --> <input id="i2" tabindex="1"/> <div id="d1" tabindex="3"/>OK</div> <!-- custom button implemented by the widget developer and marked as focus-able by using tabindex --> </div> <input id="textbox2" tabindex="2" /> <!-- tabindex: 2 set in the Modeler --> <input id="textbox3" tabindex="4" /> <!-- tabindex: 4 set in the Modeler -->
A Mendix developer placed 4 widgets on the page, three textboxes and one complex custom widget. And the desired tab order is following:
textbox3. Which is set by placing tab orders in the Modeler.
The developer of the complex widget wants to provide a custom tab order
d1inside of the widget by simply placing
tabindex properties. Also a custom button is implemented in the widget using focus-able
The focus order on pressing
Tab is following:
- Back to
Hope it explains the necessity of having the custom focusindex property in our DOM structure."