Koda

Welcome to Koda bug tracker!

At the moment you can post bugreports or suggestions anonymously. But registered users have some benefits: attaching files, commenting, voting, tracking tasks e.t.c.

Due some asshole started spamming tracker, now (at least for some time) it’s not allowed to create anonymous tasks. Sorry for unconvenience.

In edit fields you can use DokuWiki syntax for formatting.

Tasklist

FS#170 - Tab Order - 2 cases

Attached to Project: Koda
Opened by Chris Haslam (c.haslam) - Tuesday, 08 February 2011, 08:48 GMT+3
Type Feature Request
Category Application
Status Assigned
Assigned To Admin (Lazycat)
Operating System All
Severity Low
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

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

This task depends upon

Comment by Admin (Lazycat) - Tuesday, 08 February 2011, 13:53 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Wednesday, 09 February 2011, 07:11 GMT+3

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.

Comment by Admin (Lazycat) - Tuesday, 15 February 2011, 12:15 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Wednesday, 16 February 2011, 08:16 GMT+3

I look forward to trying it in the beta version.

...chris

Comment by Chris Haslam (c.haslam) - Sunday, 27 February 2011, 23:52 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Monday, 28 February 2011, 00:12 GMT+3

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?

Comment by Chris Haslam (c.haslam) - Monday, 28 February 2011, 00:20 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Saturday, 30 April 2011, 17:46 GMT+3

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.
Comment by Chris Haslam (c.haslam) - Saturday, 07 May 2011, 06:16 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Sunday, 08 May 2011, 08:45 GMT+3

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.

Comment by Chris Haslam (c.haslam) - Monday, 23 May 2011, 06:48 GMT+3

See FS#290

Loading...