• Status Assigned
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category Application
  • Assigned To
    Admin
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Development
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Koda
Opened by Chris Haslam - 08.02.2011

FS#170 - Tab Order - 2 cases

As well as Edit→Tab Order, I now see Tab Order in Object Inspector (e.g. for Button). (perhaps Tab Stop Number would be more precise). So I think that there are two cases:

  1. Setting the tab order for all controls, and
  2. Setting the tab stop number for the currently selected control.

Tab Order Editor handles the first case.



Now for the second case.

In Object Inspector, Koda permits the user to enter the tab stop number. But what if he enters 2, and there is already a control that has tab stop 2. What happens?

I think it would be preferable to have clicking to the right of tab order bring up a dialog something like my screenshot:

This would allow the user to position the selected control relative to other controls. Note that he would no longer be concerned with the tab stop number, so conflicts in number could not occur.

IMHO

...chris

Admin
Admin commented on 08.02.2011 10:53

2. It's exchanging number with that control.

But I'm agree, this is not obvious.

About dialog, isn't this almost the same as current tab editor? It's possible to call TabEditor from property inspector.

Chris Haslam commented on 09.02.2011 04:11

I think that exchanging the number with the control that has tabstop 2 is likely to lead to confusion. I can document it, but still ...

I see no reason why the user need concern himself with numerical tabstops. Put another way, Koda is a visual editor, so make it as visual as possible.

I assume, for the time being, that Object Inspector retains some way of setting tabstops, i.e. that there is a property for each selected control called Tabstop. So the question is: is it numerical or a ... leading to a dialog. I would prefer a ...

Yes, Tab Editor and the dialog in my screen shot both deal with tabstops, but their scopes are different. Tab Editor's scope is all controls, but the scope of my dialog is only the currently selected control.

I have changed my screen shot a bit. Its scope is now clearly ListBox1. For obvious reasons, the drop-down doesn't show ListBox1. An alternative would be to use your Tab Editor code, but with the constraint that the focus is always (in my example) on ListBox1, so the arrow buttons move ListBox1. But I think that having two different dialogs would be clearer for the user as to what the scope is.

So I feel that if Tabstop is shown in Object Inspector as a property of a control it should be set visually in a dialog specific to a selected control.

If a dialog is used to set tab order (whether it is Tab Editor or my dialog), I think the property in Object Inspector should be called "Tab order" not "Tab stop", because to me "tab stops" are numeric.

Admin
Admin commented on 15.02.2011 09:15

I'm have nothing opposite to change plain numeric to dialog. I'm not quite sure about convenience of dialog in this form. But generally I like the idea, think we can try, this can be changed while in beta stage.

Chris Haslam commented on 16.02.2011 05:16

I look forward to trying it in the beta version.

...chris

Chris Haslam commented on 27.02.2011 20:52

I have another comment about Tab Order. The user may wish some controls to be in the tab order, but others not to be reachable by tabbing. For example, I think he will usually want buttons and checkboxes to be reachable with the tab key, but not labels.

So I am thinking that the current Tab property should be redefined: rather than its value being a number, I suggest that it be True or False. Going further, if it has True/False values, it might be called Tabable or In tab order.

The default value might depend on the control: False for Labels (and possibly a few other controls), True for all others.

How does this affect a .kxf file? I suggest that a non-tabable control have TabOrder set to -1. Tabable controls would have TabOrder values >= 0.

I do not see in the AutoIt Help how to set whether a control can be reached by tabbing. But it seems to me that skipping a control could be done in code. For example, to skip lblCat:

  • for MessageLoop Mode:
Case lblCat
   Send("{Tab}")
  • for OnEventMode:
GUICtrlSetOnEvent("lblCat", "lblCatClick")
Func lblCatClick()
   Send("{Tab}")
   EndFunc

There may be better ways of doing it.

BTW in 1.7.3.2.0, I added a label to my suggestion for Current Form Generating Options. I tried tabbing to it. I don't seem to be able to reach this label by tabbing. Perhaps this is by design. In Object Inspector, for this label, Tab Order is 7. The .kxf file is attached.

Chris Haslam commented on 27.02.2011 21:12

I have written in documentation | Tab Order Editor: AutoIt does not allow tabbing to Group and Tab controls.

This is based on experimentation.

But surprisingly, in Object Inspector, Tab Order does show for a Group. Is this a bug?

Chris Haslam commented on 27.02.2011 21:20

I am wondering whether, while you are changing this part of the Koda code, you might consider adding a column to the Editor dialog: Caption. This would replace hovering for a tell-tale. I think that this would make it easier for the user, particularly when he has many checkboxes, etc.

Chris Haslam commented on 30.04.2011 13:46

I notice that when I run a script and Tab around, a label is not activated by tabbing. So it is not tab stop, in spite of having TabOrder 0.

But TabOrder Editor shows Label1.

It appears that AutoIt or Windows is omitting Label1 from the tab sequence. To me, this is the way it should be.

So I suggest that:

  • TabOrder not be a property of TALabel
  • TabOrder Editor not show labels.
Chris Haslam commented on 07.05.2011 02:16

Perhaps Icon and Pic should not be in tab order at all.

How does one remove a control from the tab order? I thought -1 might do it, but it does not seem to.

Chris Haslam commented on 08.05.2011 04:45

Sorry to add another issue to this already complex task!

I created a Button (and changed nothing in Object Inspector). WS_TABSTOP is checked and Koda assigned it TabOrder 7 and it appears in Tab Order Editor.

I created a Label (and changed nothing in Object Inspector). WS_TABSTOP is unchecked but Koda assigned it TabOrder 8 and it appears in Tab Order Editor.

So there is inconsistency: TabOrder and Tab Order Editor agree, but they don't always agree with WS_TABSTOP.

I don't really know what to suggest. As far as I can see, there is no mechanism at the moment for a non-substitute control not being in the tab order. Perhaps AutoIt has no mechanism for a control not having WS_TABSTOP set.

Chris Haslam commented on 23.05.2011 02:48

See FS#290

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing