All Projects

If a dialog form is created with the certain style bits (s. below) in Koda the window height in the generated AutoIt code is set to ClientHeight + 1 instead of Height which cuts off a stripe of the height of the window’s title bar (mostly 26 px) at the bottom of the form at the time is displayed from the script.

Example as followed.

SampleDialog.kxf

<object type="TAForm" name="dlgTest">
	<properties>
		<property name="Left" vt="Int16">1626</property>
		<property name="Top" vt="Int16">262</property>
		<property name="Width" vt="Int16">321</property>
		<property name="Height" vt="Int16">407</property>
		<property name="Caption" vt="String">Sample Dialog</property>
		<property name="Color" vt="Ident">clBtnFace</property>
		<property name="Font.Charset" vt="Ident">DEFAULT_CHARSET</property>
		<property name="Font.Color" vt="Ident">clWindowText</property>
		<property name="Font.Height" vt="Int8">-11</property>
		<property name="Font.Name" vt="String">MS Sans Serif</property>
		<property name="Font.Style" vt="Set"/>
		<property name="OldCreateOrder" vt="False">False</property>
		<property name="Position" vt="Ident">poDesktopCenter</property>
		<property name="ParentForm" vt="String">owner</property>
		<property name="Style" vt="Int32">273154176</property>
		<property name="ExStyle" vt="Int8">0</property>
		<property name="Version" vt="String">1.04</property>
		<property name="PixelsPerInch" vt="Int8">96</property>
		<property name="TextHeight" vt="Int8">13</property>
	</properties>
</object>

SampleDialog.au3 (generated)

#Region ### START Koda GUI section ### Form=SampleDialog.kxf
    Local $dlgTest = GUICreate("Sample Dialog", 314, 374, -1, -1, BitOR($WS_SYSMENU,$WS_DLGFRAME,$DS_MODALFRAME), 0, $owner)
#EndRegion ### END Koda GUI section ###

Microsoft says of DS_FOREGROUND:

Causes the system to use the SetForegroundWindow function to bring the dialog box to the foreground

AutoIt does not seem to provide SetForegroundWindow functionality.

So I suggest the DS_FOREGROUND be removed.

WS_EX_TOPMOST provides “stay on top”.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

The doc as I received it says:

Starting 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 quite understand.

Does this say the same thing:

Windows XP and up set the opened height of a Combobox. The Height property is the height of the closed Combobox.

My playing around shows that the height of the closed control is fixed in Design Area and at run-time (perhaps font-size dependent), and that when opened, the height is sufficient to show at least 15 items.

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.

Also: should I remove mention if image from SS_CENTERIMAGE?

AutoIt has constants for them

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

I am inclined to think that Styles and ExStyles should be added to the documentation – for each control in the Controls section. That way, Koda goes even further to being the “one stop” place for GUIs.

Any thoughts?

Include would make the process less painful. There are some WS_ constants that are available to almost all controls, so it would be nice to be able to include multiple rows of a table in one VAR. Can Include do this?

I would copy the stuff from AutoIt, perhaps doing some re-wording where I can make things clearer (but mostly the AutoIt doc is fairly clear on Styles).

The Styles for Form are a problem: Microsoft defined them in odd ways. I can’t do much about that!

Should I create a commstyle page like commctrl?

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.

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)

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.

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.

menu_align.png had Horizontal rather than Horizontally. etc.

I uploaded an updated version, but the old version still shows.

New version is attached.

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

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

See attached for AutoIt error.

Please

Please update with your color scheme

Please add the ability to use array names in the Object Inspector for the control names: ControlName[Index]

Perhaps also a “Insert in” and “Allow copy” menu items, so user doesn’t have to close the form and reopen it to regain full editing capability over controls.

...chris

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.

Please update this image with your selection color.

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?

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.

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

Please update controls_tab_add.png, i.e. with Add a Page rather than New Page. I could do it, but my colors are different from yours.

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.

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

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?

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?

On the first launch of the day, I got an exception error. Screen shot attached.

The other screen shot is after clicking OK to the message box.

I was able to close Koda.

Then I was able to launch Koda normally.

Weird!

The correct English usage is Contents.

I understand why there are four tabs, but I wonder if there is a better way of organizing them.

I find that I easily forget where to find a control: which tab is it on? and which icon is it? A few icons are clear as to what the control is, but some are not. I often have to wait for the telltale to show to be sure. This is not the fault of the picture on the icon: icons are only a limited number of pixels.

So Idea #1 is to add a main menu item called Controls, with all the controls as sub-items. In the future, it may be necessary to have 3 levels, with Native and UDFs as the second level.

Idea #2 is to group the controls alphabetically, e.g. A to E for the first tab, F to M for the second, etc.

I am finding that it is very easy to loose the last menu item created. I was testing Creating a menu control.

I suggest that Menu Designer have OK and Cancel buttons. This would be user friendly – allowing a user to back out of a change – and could ensure that the last menu item added does indeed get added to the menu control.

I don’t see why OnClick brings up a dialog.

It only has two values: Notify and don’t notify.

It seems to me that it would be more obvious if it were called Notify and its values were True and False. It would then work like, for example, Enabled.

Just a thought.

I note that the documentation calls this “Templates Gallery” but 1.7.3 .0 and the screen shot call it “Form Templates”. I suggest that “Form Templates” is the better name: it fits with “Code Generation Templates”. I will change the documentation to “Form Templates”.

I note that 1.7.3.0 shows two tabs: “Standard” and “My own templates”, but that the 1.7.3.0 help and the documentation shows only “Standard”. Further, one of the templates in the “My own templates” tab has no icon. I suggest that “My own templates” be dropped. THe documentation will tell the user how to add templates and tabs.

How can the user add a description and icon to a template he creates?

How can the user delete a template he creates?

How can the user delete a tab that he creates?

Are the Windows here all the windows in Koda, i.e. Object Treeview, Object Inspector, Form List, and forms?

I have not figured out what the following checkboxes really do:

• Keep standard layout

• Snap wimdows (to the grid?)

• Choices in Size and position saving (especially the difference between Don’t save abd Manually)

I have looked at the doc as I received it. It doesn’t help.

BTW the screen shot here is obsolete: we need a new one. Please supply.

BTW “Always full expand” should be “Always fully expand”

MS‘s mess (discussed previously) is driving me nuts!

So for Styles of TAForm I suggest that you add some pseudo-styles. Some I think of: Title bar, Close box, Minimize box, Normal frame, Dialog frame, perhaps Modal.

There are two ways you could add them:

1. Put them in the Styles tab, at the top of the list, or

1. Put a Clearer styles for Form checkbox in Options | Designer. When it is checked, have Koda replace all the WS styles which are equivalent to pseudo-styles.

You have more experience than I do with these bloody styles. Perhaps there is no way to get around MS‘s confusion!

There is another way: document the translation from pseudo-styles to WS_ constants in Controls | Form. For that I would need your help.

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?

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)

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.