Hello,
I have a step with several input fields, on the first time I’m building this step, the tab order is exactly as the fields I entered, but if I have to add another field afterwards in the middle of the window, the tab order will not be arranged and can’t be reaarrange anymore.
So, can you add an attribute of tab order to the input object ?
Thank you,
Amit
Hi,
Tulip decides the tab order in the order controls are drawn on the step. One way to change the tab order for the controls added at a later stage is to recreate all the controls in the screen in the same order as desired tab order. Please try Ctrl+X and Ctrol+V for each control on screen in the desired tab order sequence, this will recreate all controls on screen and Tulip will create the tab order inline with that. Not an ideal solution but should present the expected order. Hope this help.
Ashish.
Hi,
I know that this is the current way that Tulip works and it is not acceptable, because of that I wrote this topic under product suggestions, so I hope that the developers of Tulip will fix this issue and somehow will add a new attribute to this object of tab order so the user will be able to decide by him self about the order.
Thank you,
Amit
Agree that this would be a useful feature.
Hello!
There’s been some discussion about our tab order recently during office hours, and I wanted to clarify how it currently functions.
Currently, the tab order corresponds to the placement sequence of widgets within a step’s widget list, located in the app editor’s left side panel. As you add widgets to the canvas, they are automatically placed above the previously added ones. As you progress upwards, each successive widget appears one after the other, in ascending order. This order mirrors the rendering direction in the DOM (Document Object Model) where each newly added component is placed above the previous one.To better visualize this, let’s take two scenarios.
I’m attaching a helpful video that @Beth created which demonstrates this in a visual way:
I hope these examples clarify our current tab order logic, and we’re thinking about how we can improve the behaviour!
Hi @MaxN-C,
thanks for clarifying that.
I want to point out some behavior that might be not intuitive, so that app developers have this in mind when using the tab order.
Most of this should get fixed by TULIP in my opinion.
A Text and a Variable (also an array) is implemented as button in the dom (the html element). It has no tabindex, therefore it behaves as a standard button in html. This makes it selectable by tab key.
This is actually annoying behavior (the text gets a frame of the size of the widget. It has no function, but you have to tab through to get to where you actually want to get to.
Buttons do have functionality. You might want to select them and hit enter (I guess space would work by default if you remove the negative tabindex) to start its trigger. Unfortunately Buttons have a tabindex=“1” in TULIP, so they are ignored by tab key. (I don’t know why TULIP differs from default here)
by encouraging the use of the tab key, you will get more people trying to use enter after an input. Unfortunately you cant link to a trigger, that means you have to create and maintain the same triggers as button trigger and as on enter trigger for the input (redundant work / error potential)
widgets hidden behind other widgets are reachable by hitting the tab key
widgets that are hidden, by moving it away from the canvas are not ignored by the tab key. This will cause the canvas to expand and shift on the screen.
Original:
Hidden text highlighted by tab:
You could add a checkbox on the widgets list of the step. If checked, the tabindex is set to 0 (focusable by tab). If unchecked, tabindes gets set to “-1” (not focusable by tab)
Some elements have 0 as default and only needs the attribute if “-1” is wanted.
(e.g.: <button> and <a>)
Also you should change the default behaviour that variables and texts are “-1” and actual buttons are “0”
Hi Max,
You showed me about a year ago in a meeting what how do you think that tab order and auto focus on a text box should be active and it was wonderful but since than, nothing of that was implemented, it was great gui back then.
Anyway, maybe I can simplify what @thorsten.langner wrote, maybe by adding an attribute to desire objects on screen that will set tab index for each one may respond to all scenarios he mentioned.
If I have, for example, 10 widgets on screen 4 inputs that you can see, 2 hidden ones and other 4 widgets like labels or buttons, I want only those 4 input box to have ability of tab order for the users so only on them, the developer will put numbers from 1 to 4 (by expected order) and all other will have blank value in this attribute, what do you think about that ?
This is how VB6 is working, also Delphi and web dynpro in SAP. In ABAP (SAP language) it doesn’t exists but there you can put focus on each text box that you like and move through all of them by events, another way that you don’t have in Tulip.
If after my long description, you still have any questions, I’ll be glad to answer them.
Thank you,
Amit Berku
Hi @Amit,
I was also thinking of using the tabindex for tab order. But usually this is seen as bad practice in html.
Since you can actually give it an order, it is only about a logical default "on / off " and an easy way to influence the behaviour (also on / off).
Maybe a over simplification on my part, but perhaps a better intermediate solution would be to at least order the tab sequence to mirror the widgets in the step menu. If I could drag and drop the order there and it be reflected in the tab sequence I think that would solve the issue nicely.
Not sure if I got you wrong, but that is exactly how it’s done…
The bottom one will be the first in tab order and the top one the last, as long as the widget is focusable by tab at all…
I could swear I tried that and it didn’t work as expected, but then again I probably expected it to work top down.
