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#290 - Tab Sequence (Order) Editor: a proposal

Attached to Project: Koda
Opened by Chris Haslam (c.haslam) - Monday, 23 May 2011, 06:45 GMT+3
Type Bug Report
Category Application
Status Unconfirmed
Assigned To No-one
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

I am attaching a screen shot of what I have in mind. This dialog would be accessible from Edit | Tab Order and from each real (not substitute) control. From the menu, it would appear as in the screen shot. From a control, if the control is a group, the group would be highlighted. If the control is not in a group, Form1 would be highlighted.

Note that Koda would not show sequence numbers of tabstops. This would be internal to fd.exe. Users won’t need sequence numbers if they have the information visually. The user would no longer have to think the numbers. With the proposed dialog, he would get all the tabstop info in one place. This makes sense to me because tabstops are really inter-control rather than intra-control.

Optimally, Add would only be enabled when the Not tabstops .. list has focus and an item is selected. Up, Down and Remove would only be enabled when the Tabstops list has focus and an item is selected (and of course, Up would be disabled if the top item is selected, and Down would disabled if the last item is selected).

If this proposal is implemented, I would suggest:

  • In Properties, Tab Order would be replaced with Tabstop, which would be read-only boolean , with a ... button to the right to access the Editor
  • In Styles, WS_TABSTOP would be removed. fd.exe would continue to track WS_TABSTOP.

It is possible that, early in designing a form, a user may wish to make some controls tabstops, and others not; he may wish to refine the order later. So the Tabstop property could be read-write. If it is, I suggest:

  • If the user changes Tabstop for a control from False to True, the control would be placed at the end of the Tabstops list
  • If the user changes Tabstop for a control from True to False, the control would be moved from the Tabstops list to the Not tabstops, but can be list.
  • For Label (and other controls that cannot be tabbed to), the Tabstop property would be set to False and would be read-only.

I acknowledge that AutoIt tabs in the order in which calls to GuiCtrl functions that specify WS_TABSTOP appear in the script. The code generator could generate in the order shown: first the Tabstop list (with WS_TABSTOP set), then the others (without TABSTOP set), although this is not requisite.

I think that this proposal mostly improves the UI. It does clear up what I called an inconsistency in my previous post – although I may be wrong. I think that the code under the hood will change very little.

I have done some playing with (and thinking about) the names of the lists. Alternative names are: Un-tabable, Potential tabstops and Tabstops. I don’t like Un-tabable because it is bad English.

This task depends upon

Loading...