All Projects

Currently, the development of the Koda project is frozen, the ability to register new users and add new bugreports is disabled.

IDProjectCategory  ascTask TypeSeveritySummaryStatusOpened byLast Edited
226KodaApplicationBug ReportLowMenuItem | RadioItemUnconfirmedChris Haslam05.05.20113 Task Description

Either MenuItem | RadioItem is not working or I don’t understand it. .kxf file, attached, generated:

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Menu radio test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
$mnuFile = GUICtrlCreateMenu("&File")
$mnuOpen = GUICtrlCreateMenuItem("Open", $mnuFile, -1 , 1)
$mnuSave = GUICtrlCreateMenuItem("Save", $mnuFile, -1 , 1)
$MenuItem1 = GUICtrlCreateMenuItem("", $mnuFile)
$mnuExit = GUICtrlCreateMenuItem("Exit", $mnuFile)
$mnuEdit = GUICtrlCreateMenu("&Edit")
$mnuOpts = GUICtrlCreateMenu("&Options")
$mnuHelp = GUICtrlCreateMenu("&Help")
$Label1 = GUICtrlCreateLabel("Label1", 224, 184, 36, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
 
While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
 
	EndSwitch
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Menu radio test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
$mnuFile = GUICtrlCreateMenu("&File")
$mnuOpen = GUICtrlCreateMenuItem("Open", $mnuFile, -1 , 1)
$mnuSave = GUICtrlCreateMenuItem("Save", $mnuFile, -1 , 1)
$MenuItem1 = GUICtrlCreateMenuItem("", $mnuFile)
$mnuExit = GUICtrlCreateMenuItem("Exit", $mnuFile)
$mnuEdit = GUICtrlCreateMenu("&Edit")
$mnuOpts = GUICtrlCreateMenu("&Options")
$mnuHelp = GUICtrlCreateMenu("&Help")
$Label1 = GUICtrlCreateLabel("Label1", 224, 184, 36, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
 
While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
 
	EndSwitch
WEnd
229KodaApplicationBug ReportLowData separator charAssignedChris Haslam05.05.20114 Task Description

I find it a little surprising that Data separator char is in Options but not in Generating Options. My understanding is that it is not saved with the form, so if the form was created when Options | Data separator char was (say) $ and the user later adds a ListBox where one of the items is $10, he has to recreate his form from scratch.

Thoughts?

230KodaApplicationBug ReportLowCombo: ItemIndex and TextUnconfirmedChris Haslam05.05.20112 Task Description

I take ItemIndex to be the ordinal number of the Item that is shown initially ref 1).

With a List, I have played with Text. It seems always to show the Item with the ordinal that is assigned to ItemIndex. So why does Koda have both ItemIndex and Text? Or should Text be read-only?

231KodaApplicationBug ReportLowCombo: RemarksUnconfirmedChris Haslam04.05.20111 Task Description

The doc
from WinXP the “visual” height of combo cannot be set. Height parameter is showing height of opened combo. Koda allow you to change it manually.

I don’t understand. Is the doc saying that the collapsed height is fixed by XP and up, but that the user can set (with the Height property) the expanded height? If so.I have not been able to see this.

232KodaApplicationBug ReportLowControl | PicUnconfirmedChris Haslam04.05.20111 Task Description

I have written:

sRealSize - Width and height are determined by original size of image

Is this correct?

233KodaApplicationBug ReportLowCannot set OnClick to be noneUnconfirmedMartin Gibson04.05.20112 Task Description

The OnClick property does not work for me if I choose none. With none I expect that there will be no line GuiCtrlSetOnEvent for that control and for lots of things, like labels, I might not have an event.

234KodaApplicationBug ReportLowDummy: notifyAssignedChris Haslam04.05.20114 Task Description

I read in the doc:

The control will “notify” as normal

but do not see an OnClick property.

So how does the user tell a Dummy control to notify?

235KodaApplicationBug ReportLowSlider | PositionWaiting feedbackChris Haslam11.05.20115 Task Description

I take Position to be the initial position (value) of the slider.

I set Position to 40. It appeared not to generate any code. I did run. The slider showed at the left end of its range.

236KodaApplicationBug ReportLowTreeView :PropertiesUnconfirmedChris Haslam04.05.20111 Task Description

I suggest that Images be called ImageList. This will be clearer.

I suggest that Items be called Nodes.

237KodaApplicationBug ReportLowListView PropertiesUnconfirmedChris Haslam04.05.2011 Task Description

I suggest that Images be called ImageList. Clearer

Alignment

I read the info on Alignment:

According to MSDN, the alignment of the leftmost column is always left-justified; it cannot be changed.

MSDN says in full:

If a column is added to a list-view control with index 0 (the leftmost column), it is always LVCFMT_LEFT. Setting other flags on column 0 does not override that alignment. Therefore if you keep inserting columns with index 0, the text in all columns are left-aligned. If you want the first column to be right-aligned or centered you can make a dummy column, then insert one or more columns with index 1 or higher and specify the alignment you require. Finally delete the dummy column.
  • Based on MSDN, Koda would not allow me to right justify column 0, Animal
  • So, following the MSDN procedure, I inserted another column and moved it up to be column 0.
  • I set Animal, now column 1, to right justified
  • I deleted column 0.

The form ran OK. The part of the generated code that does the ListView is here:

$ListView2 = GUICtrlCreateListView("Animal|Coat|Feet", 96, 384, 169, 113)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 0, 50)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 1, 50)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 2, 50)
_GUICtrlListView_JustifyColumn(GUICtrlGetHandle($ListView2), 0, 1)
$ListView2_0 = GUICtrlCreateListViewItem("Lucas|furry|paws", $List

I am wondering whether Koda would be able to do the work-around automatically, rather than the user having to do it manually. Perhaps Koda would need to create a zero-width column 0 so Object Inspector would allow the first column that shows in Collection editor to be right or center justified.

Just a thought.

240KodaApplicationBug ReportLowTab Control: Focus and reorganizing pagesUnconfirmedChris Haslam06.05.20114 Task Description

While Alt-Left and Alt-Right have worked for me, I have just spent several minutes trying to get Alt-Left to work for me.

Screen shot and .kxf file are attached.

I wish I could be clearer as to what is happening. Alt-Left seems not to be working because the focus is not on TabSheet1. I also notice that the Form is active but Koda is not: odd.

When I first tried Alt-Left and Alt-Right they didn’t work. Then somehow they did.

241KodaApplicationBug ReportLowTab: HintUnconfirmedChris Haslam05.05.20111 Task Description

The doc says;

If one of pages has “Hint” property set, Koda will always generate GUICtrlSetTip for first page - this is the only way to correct setting tip to previous pages.

I am not sure what this means.

Here is what I think it may mean:

If you set a Hint for a page other than the first page, Koda will also generate a Hint for the first page.

Does this mean that a Hint will be set for all pages?

Is this an AutoIt limitation?

Is the Hint on the first page the same as on the subsequent page?

242KodaApplicationFeature RequestLowIP address: EnabledAssignedChris Haslam11.05.20115 Task Description

I am surprised that there is no Enabled property in Object Inspector

243KodaApplicationBug ReportLowToolbar | Button | HeightUnconfirmedChris Haslam05.05.20111 Task Description
  1. Selected Height value
  2. Pressed Del
  3. Pressed Enter

Exception
Exception handled 2011-05-04 at 22:35:49 by
is not a valid integer
Address:
about Source of
Method: Line:

Same thing happened when Backspace key (rather than Del) was pressed.

245KodaApplicationBug ReportLowToolbar: Properties: discrepancy between Koda and the d...UnconfirmedChris Haslam05.05.20111 Task Description

The following properties are in Object Inspector but not in the doc:

  • TAToolbar - Enabled, Height, Hint, Tab Order, Top, Visible, Width
  • TAToolButton - Caption, Enabled, Height, Hint, ImageIndex, Top, Visible, Width

Please tell me which should be added to the doc. (Some I know, e.g. ImageIndex)

246KodaApplicationRegular TaskLowOptions | Options | General | Recent Files 2UnconfirmedChris Haslam06.05.20111 Task Description

I notice that the caption in 1.7.3.1 is Number of recent file list. This does not make sense to me. It makes it look like recent file list has an ID number (or something).

I wrote:

I suggest that the caption be changed to Recent files in File menu. This is consistent with Undo levels. I also think that it is clearer.

Other wordings are possible.

Number of is redundant: the input box shows numbers.

:-)

247KodaApplicationBug ReportLowKoda menu | Help | ContentUnconfirmedChris Haslam05.05.2011 Task Description

The correct English usage is Contents. :-)

249KodaApplicationBug ReportLowTab control: Hint being set for ccontrol on a pageUnconfirmedChris Haslam06.05.2011 Task Description

The attached .kxf file, when run, shows a Hint for the Label on the third Page. The Hint should be for the Page.

250KodaApplicationBug ReportLowToolbar : controls_toolbutton_add.pngUnconfirmedChris Haslam06.05.20111 Task Description

Please update this image with your selection color.

251KodaApplicationBug ReportLowToolbar | Style | tbsDropDownUnconfirmedChris Haslam06.05.2011 Task Description

A button with tbsDropDown does not show correctly when the form is run. Koda generates

_GUICtrlToolbar_AddButton($ToolBar1, 0, 20, 0, $BTNS_DROPDOWN)

The AutoIt help says:

_GUICtrlToolbar_AddButton($hWnd, $iID, $iImage[, $iString = 0[, $iStyle = 0[, $iState = 4[, $iParam = 0]]]])

Is this a code generator problem? Or is _GUICtrlToolbar flaky?

252KodaApplicationBug ReportLowMy first pass through the documentation is now completeUnconfirmedChris Haslam06.05.2011 Task Description

My first pass through the documentation is now complete, except for issues I have raised in open Bugtracker tasks. I will be proceeding to Pass 2. This will include replacing many #term_definitions with #remarks_headers.

255KodaApplicationBug ReportLowDummy: How to show Context MenuUnconfirmedChris Haslam11.05.20111 Task Description

How can I get a context menu to show when I press the accelerator key?

See attached for AutoIt error.

258KodaApplicationBug ReportLowdialog_generating_options.png is out of dateUnconfirmedChris Haslam08.05.20111 Task Description

Please update with your color scheme

259KodaApplicationBug ReportLowproped_treeview_editor.png: update from Item to NodeUnconfirmedChris Haslam08.05.20111 Task Description

Please

261KodaApplicationFeature RequestLowDisable a tabstopUnconfirmedChris Haslam24.05.20117 Task Description

An example from External Link:

GUICtrlCreateButton("Two", 10, 140, 80, 30)
_WinAPI_SetWindowLong(GUICtrlGetHandle(-1), $GWL_STYLE, BitAND(_WinAPI_GetWindowLong(GUICtrlGetHandle(-1), $GWL_STYLE), BitNOT($WS_TABSTOP)))

But first the inconsistency between Tab Order and WS_TABSTOP needs to be resolved.

264KodaApplicationBug ReportLowChoose Script: move from startup to Tools | Update Scri...UnconfirmedChris Haslam23.05.20112 Task Description

I think that it would be more user-friendly to move Choose Script from start-up to when the info is needed, i.e. when the user first does Tools | Update Script in a session (and, of course, when more than one .au3 file uses the active form).

Choose Script would then be changed to ask: “Update which script?”. Otherwise the dialog would be the same as it is now.

Moving Choose Script would significantly help with the documentation effort. It is not documented because I haven’t thought of where to weave it in.

265KodaApplicationBug ReportLowInputBox+UpDown | disabled : Code Generator errorAssignedChris Haslam17.05.20111 Task Description

I set InputBox | Enabled to False. Koda generated:

$Input1 = GUICtrlCreateInput("1", 112, 56, 96, 21, 0)
$Updown1 = GUICtrlCreateUpdown($Input1)
GUICtrlSetLimit(-1, 1, 100)
GUICtrlSetState(-1, $GUI_DISABLE)

It should be:

$Input1 = GUICtrlCreateInput("1", 112, 56, 96, 21, 0)
GUICtrlSetState(-1, $GUI_DISABLE)
$Updown1 = GUICtrlCreateUpdown($Input1)
GUICtrlSetLimit(-1, 1, 100)
266KodaApplicationFeature RequestLowCheckbox: initialize with $GUI_INDETERMINATEPostponedChris Haslam17.05.20111 Task Description

When BS_3STATE is checked, Check would offer True, Indeterminate and False. If Indeterminate is too long, Gray would fit.

If the user chose Gray and subsequently unchecked BS_3STATE, Check would automatically become False.

268KodaApplicationFeature RequestLowForm | WS_EX_ACCEPTFILES requires GUI_DROPACCEPTED in o...UnconfirmedChris Haslam17.05.2011 Task Description

I don’t see how to check GUI_DROPACCEPTED in Edit control.

269KodaApplicationBug ReportLowForm lacks WS_EX_CLIENTEDGE and WS_EX_STATICEDGEUnconfirmedChris Haslam17.05.2011 Task Description

AutoIt has constants for them

270KodaApplicationBug ReportLowButton: SS_RIGHTJUST available but no way of specifying...UnconfirmedChris Haslam18.05.20112 Task Description

Also: should I remove mention if image from SS_CENTERIMAGE?

271KodaApplicationBug ReportLowInput styles: some suggested changesUnconfirmedChris Haslam18.05.20111 Task Description

I think that ES_MULTILINE should not appear in Object Inspector because an InputBox is by definition single-line.

ES_WANTRETURN is irrelevant to Input box because InputBox is single-line, so I think that it should not appear in Object Inspector. Same for ES_AUTOVSCROLL and WS_VSCROLL.

In C/C++, WS_GROUP is the way of marking a control as the first in a group, and another control as the last in the group. But AutoIt uses, and Koda generates, a pair of calls to GUICtrlCreateGroup. So I suggest removing WS_GROUP from TAInput in Object Inspector. The fewer styles there are, the easier it is for a user: some scrolling down is inevitable, but the less he needs to do so the less likely he is to miss a style that he needs to check or uncheck.

Koda shows WS_VISIBLE as forced, but AutoIt doesn’t. Further, WS_VISIBLE remains checked even when Visible is False. I suggest removing WS_VISIBLE.

I think that WS_CHILD only applies to Forms. So I suggest removing it from Object Inspector | TAInput.

With WS_HSCROLL checked, when a Form is run, the scroll bar is drawn over the Text. Koda insists that the Height be 21. It needs to allow a larger height when WS_HSCROLL is checked.

272KodaApplicationBug ReportLowLabel styles: some suggested changesUnconfirmedChris Haslam15.06.20111 Task Description

SS_NOTIFY is shown as checked and forced, even when OnCick has not been specified. But notification can be set/reset in OnClick. So I suggest removing SS_NOTIFY. I wonder whether SS_NOTIFY will work for a Label.

n C/C++, WS_GROUP is the way of marking a control as the first in a group, and another control as the last in the group. But AutoIt uses, and Koda generates, a pair of calls to GUICtrlCreateGroup. So I suggest removing WS_GROUP from TALabel in Object Inspector. The fewer styles there are, the easier it is for a user: some scrolling down is inevitable, but the less he needs to do so the less likely he is to miss a style that he needs to check or uncheck.

Koda shows WS_VISIBLE as forced, but AutoIt doesn’t. Further, WS_VISIBLE remains checked even when Visible is False. I suggest removing WS_VISIBLE.

I think that WS_CHILD only applies to Forms. So I suggest removing it from Object Inspector | TALabel.

273KodaApplicationBug ReportLowEdit styles: some suggested changesUnconfirmedChris Haslam09.06.20111 Task Description

I think that ES_MULTILINE should not appear in Object Inspector because an EditBox is by definition multi-line.

In C/C++, WS_GROUP is the way of marking a control as the first in a group, and another control as the last in the group. But AutoIt uses, and Koda generates, a pair of calls to GUICtrlCreateGroup. So I suggest removing WS_GROUP from TAEdit in Object Inspector. The fewer styles there are, the easier it is for a user: some scrolling down is inevitable, but the less he needs to do so the less likely he is to miss a style that he needs to check or uncheck.

Koda shows WS_VISIBLE as forced, but AutoIt doesn’t. Further, WS_VISIBLE remains checked even when Visible is False. I suggest removing WS_VISIBLE.

I think that WS_CHILD only applies to Forms. So I suggest removing it from Object Inspector | TAEdit.

274KodaApplicationBug ReportLowButton styles: some suggested changesUnconfirmedChris Haslam11.06.20112 Task Description

Microsoft and AutoIt say that BS_PUSHLIKE applies to Checkbox and Radio, but not to Button. I suggest removing it from Button.

BS_ICON and BS_BITMAP: I think these are redundant because the user tells Koda which icon or bitmap to use in Picture.

WS_GROUP, WS_VISIBLE and WS_CHILD: see discussion in FS$273

275KodaApplicationBug ReportLowCheckbox styles: some suggested changesUnconfirmedChris Haslam06.06.20112 Task Description

WS_GROUP, WS_VISIBLE and WS_CHILD: see discussion in FS#273

276KodaApplicationBug ReportLowTAComboBox: Height behaviour abnormalAssignedChris Haslam19.05.2011 Task Description

With CBS_SIMPLE set, at design time, when I mouse to change the height of the control, the Height property does not change.

277KodaApplicationBug ReportLowMenutitem: Object Inspector shows styles and exstyles f...UnconfirmedChris Haslam10.06.20114 Task Description

...chris

278KodaApplicationBug ReportLowTAGroup styles - some suggestionsUnconfirmedChris Haslam19.05.2011 Task Description

BS_RIGHTBUTTON: does not seem to do anything. So perhaps remove it from OI.

BS_GROUPBOX: redundant in TAGroup. So perhaps remove it from OI.

WS_GROUP: irrelevant to code generation. AutoIt normally uses GuiCtrlCreateGroup. So perhaps remove it from OI.

279KodaApplicationBug ReportLowGraphics: graphic may not show in controlAssignedChris Haslam14.06.20114 Task Description

If the graphic created in Graphics Editor is too far down in the GE design area, and/or is to far the right, it may not be seen in the design area.

There are 3 possible solutions that I can think of:

  • Have Koda reposition the graphic, and perhaps decrease it in size, so that all of it shows in the Graphics control
  • Make the size of the design area in the Graphics Editor the same size as the Graphics control
  • Add to the Graphics Editor the right and bottom bounds of the control, showing them as thick dashed lines. It would then be the responsibility of the user either to keep within the bounded design area or, when he leaves GE, to change the size of the control to fit the graphics.
280KodaApplicationBug ReportLowGraphics styles: some suggestionsUnconfirmedChris Haslam11.06.20114 Task Description

SS_LEFTNOWORDWRAP appears in OI but is not, I think, applicable to a control that has no text

SS_SIMPLE seems to do nothing

SS_ETCHEDHORZ reduces the Height to 2, and when the Height is restored in OI, the graphic is not drawn. Indeed, Graphics Editor no longer shows the graphic although Item still shows 1 item.

SS_ETCHEDVERT behaves similarly except that the Width increased to about 630.

These tests were with a graphic that was larger than the control.

281KodaApplicationBug ReportLowTAPic styles: some suggestionsUnconfirmedChris Haslam20.05.2011 Task Description

I suggest not showing SS_BITMAP in OI because it is redundant and, for AutoIt, incorrect: AutoIt supports BMP, JPG, and GIF.

For transparency, Form needs WS_EX_LAYERED, so perhaps this should be added to Form.

I do not see how SS_NOPREFIX applies to Pic.

282KodaApplicationBug ReportLowIcon styles: some suggestionsUnconfirmedChris Haslam11.06.20112 Task Description

SS_ICON: could be dropped from OI because it doesn’t add any info: TAIcon only handles, and requires, an icon.

SS_PREFIX applies to text, but TAIcon has no text.

FS#281 relates

283KodaApplicationBug ReportLowSlider styles: some suggestionsUnconfirmedChris Haslam10.06.20113 Task Description

TBS_ENABLESELRANGE, TBS_FIXEDLENGTH: I do not see a way of setting the selection range. It appears that GuiCtrlSlider... does not have selection range but _GuiCtrlSlider... does. TBS_ENABLESELRANGE is in SliderConstants.au3

TBS_NOTHUMB appears twice in OI.

284KodaApplicationBug ReportLowTreeview styles: some suggestionsUnconfirmedChris Haslam20.05.2011 Task Description

TVS_LINESATROOT is only intended by MS to work if TVS_HASLINES is also set, so Koda should check TVS_HASLINES when user checks TVS_LINESATROOT.

TVS_FULLROWSELECT is only intended by MS to work if TVS_HASLINES is not set, so Koda should uncheck TVS_HASLINES when user checks TVS_FULLROWSELECT.

TVS_NOTOOLTIPS and TVS_INFOTIP show in OI but Treeview Editor does not provide a way of entering tool tips. AutoIt only seems to provide ways of setting tool tips via GUICtrlSendMsg or by calling a UDF. So I suggest removing these two styles from OI for now.

285KodaApplicationBug ReportLowListview styles: some suggestionsUnconfirmedChris Haslam15.07.20112 Task Description
  1. Icon and SmallIcon views are available in AutoIt so LVS_ICON and LVS_SMALLICON should not be disabled. The points below assume the present situation: only List and Report view available. I have added to the doc “At this time, only Report and List views are available in Koda”.
  1. Koda can know that if if there are Columns, the view is Report else it is List. So until Icon and SmallIcon views are added, LVS_LIST and LVS_REPORT could be removed.
  1. With LVS_LIST checked, Koda generated BitOr($GUI_SS_DEF_LV,LVS_SMALLICON). It so happens that this has the same value as LVS_LIST – but untidy :-)
  1. LVS_COLUMNHEADERS only applies to Report style, so it should be disabled when LVS_LIST is checked
  1. Collection editor: if you enter only one row, no column header is created
  1. LVS_NOSORTHEADER should be removed from OI because it doesn’t work and AutoIt help says that double-click to sort rhas not been implemented.
  1. Multiple selection only works in Report view so LVS_SINGLESEL should be disabled in List view.
  1. Check LVS_SORTASCENDING and then check LVS_SORTDESCENDING: LVS_SORTASCENDING is still checked. Because mask is missing from styles.xml.
  1. LVS_AUTOARRANGE, LVS_ALIGNTOP and LVS_ALIGNLEFT are only intended for Icon and SmallIcon views, so should be removed.
  1. LVS_ALIGNTOP will not uncheck.
286KodaApplicationBug ReportLowStatusbar styles: some suggestionsAssignedChris Haslam11.06.20113 Task Description

SBARS_SIZEGRIP and SBARS_TOOLTIPS: need some extra code to be generated to work. For now, doc says “Requires ... message”.

SBARS_TOOLTIPS: no way to specify hint(s).

Remove them from OI for now?

287KodaApplicationBug ReportLowTab styles: some suggestionsUnconfirmedChris Haslam21.05.2011 Task Description

TCS_SCROLLOPPOSITE: I am not sure what this is supposed to do, but it does not seem to do anything. Googling didn’t help. Perhasp it should be removed from OI.

TCS_TOOLTIPS: There is no Hint property for a Page. Remove it from OI until there is?

See the doc for the many requirements. It would be good to have OI help the user not to choose combinations of styles that MS does not intend to work.

289KodaApplicationBug ReportLowToolbar: suggested changesUnconfirmedChris Haslam22.05.20111 Task Description

TBSTYLE_TOOLTIPS: not needed in OI because Koda knows whether Hints have been specified. So suggest remove TBSTYLE_TOOLTIPS for now.

TBSTYLE_ALTDRAG: Doc would say “Allows changing a button’s position by Alt-dragging it, rather than Shift-dragging it. Requires CCS_ADJUSTABLE”. Also doc would describe CCA_ADJUSTABLE as “enables user to add, delete, and rearrange buttons”. CCA_ADJUSTABLE is defined in Constants.au3. Suggesting adding styles is beyond my current scope, so I suggest removing TBSTYLE_ALTDRAG for now.

TBSTYLE_LIST does not seem to work, so I suggest removing it from OI.

TBSTYLE_CUSTOMERASE: Doc would say “Generates NM_CUSTOMDRAW notification codes when toolbar processes WM_ERASEBKGND messages”. This is not generated by Koda, so I suggest removing it from OI.

TBSTYLE_REGISTERDROP: Doc would say “Generates TBN_GETOBJECT notification codes to request drop target objects when the cursor passes over toolbar buttons”. This is not generated by Koda, so I suggest removing it from OI.

Extended Styles: Bug: won’t stay checked, so can’t test them.

TBSTYLE_EX_MIXEDBUTTONS: Requires TBSTYLE_LIST, which doesn’t seem to work. So I suggest removing TBSTYLE_EX_MIXEDBUTTONS from OI.

TBSTYLE_EX_HIDECLIPPEDBUTTONS: AutoIt help says “Hides partially clipped buttons”. To me buttons could only be partly clipped if buttons were added. CCS_ADJUSTABLE is not in OI, so I suggest removing TBSTYLE_EX_HIDECLIPPEDBUTTONS for now.

290KodaApplicationBug ReportLowTab Sequence (Order) Editor: a proposal UnconfirmedChris Haslam23.05.2011 Task Description

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.

Showing tasks 51 - 100 of 147 Page 2 of 3 - 1 - 2 - 3 -

Available keyboard shortcuts

Tasklist

Task Details

Task Editing