All Projects

I think it would be clearer if File | Open were split into two:

• File | Open Form
• File | Open Forms in Script

The filter on the first one would be *.kxf, and on the second *.au3

I realize that Open Forms in Script is not optimum, but I think it would be an improvement on the present situation. It could have a hint: Open all forms referenced in a script.

I suggest File | Close.

Documentation says Close, not Close Form.

...chris

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!

• I ran Koda. It brought up a form I had created earlier. Expand %var% variable was unchecked

• I created a label

• I entered %name% is a cat in Label | Caption

• I checked Expand %var% variable

• I clicked on Generate Code. ⇒ $name+”is a cat”

• I unchecked Expand %var% variable

• I clicked on Generate Code. ⇒ $name+”is a cat” again

This seems illogical.

What is the scope of Expand %var% variable? Is it specific to the form/.kxf file, or is it application level? Is it working as intended?

I noticed that labels with the style SS_ETCHEDHORZ would shrink when you switched tabs. It could be a bug in aligning to grid as it seems to step down 4 pixels on change.

The Help says “Paste previously copied/cut objects from clipboard into current cursor position”.

Attached is what actually happened when I tried it.

All I can say is that Paste didn’t work as documented. I don’t know how it should work: I am thinking about it.

For the time being, I will document it the way it actually works.

VB5 pastes to the top left of the client area, independent of where the cursor is.

...chris

I suggest that Center Horizontally in Window be changed to Center Horizontally in Parent or Center Horizontally in Container.

Why?

“Parent”: As I understand it, Koda now considers a control to be in a group if it is a son of a group in Object TreeView.

“Container”: This can mean both son in Object TreeView and what surrounds a control visually in the Form display. This term would allow for Koda automatically making a control a son of a group if it is visually within the group.

“Window”: to me, this is an imprecise term. It can mean any window.

IMHO

...chris

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.

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?

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

See attached for AutoIt error.

Dummy controls appears behind menus. Not worth to create some small hack again: new similar bug will appear surely. Better to rethink and rewrite this part of codegen.

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

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.

Please update with your color scheme

I am working on the ListView styles dialog. It is almost full-screen: about 40 controls.

I would like to keep Object Inspector on top of the Form. When I am working on controls on the right-hand side, it can sit over the left side of the form. How do I do it? OI keeps getting under the Form.

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?

Customizing fonts (by EulerG)

keyboard shortcut Ctrl+С copies of the element, although I need to copy the instance name of the element.

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 have written:

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

Is this correct?

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.

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.

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.

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?

Sometimes the defined columns of a listview are lost when copy & pasting or cut & pasting a
watch the following screencast for visual

Operating System: Windows 7 Professional (Not selectable in New Task Dropdown)

The screen shot in the doc, proped_collection_editor.png, does not agree with Koda 1.7.3.2: the caption is different.

The doc page on the Listview columns editor calls it Collection editor. It is really Column editor?

I created a duplicate of the “Events Example” template, renamed it, then edited it to my
I select the new template and generate code, the code is still based on “Events Example” instead of my template.

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.

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.

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

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.

Also: should I remove mention if image from SS_CENTERIMAGE?

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

With the attached .kxf file, the icon is visible at design time but not at run time. The icon is number 0 in shell32.dll. Other icons in shell32.dll work OK. Icon 0 in moricons.dll also does not work.

This may be an AutoIt error. If it is, is there a way for Koda to work around AutoIt’s bug?

I have not figured out how this works.

From a color wheel in another app, I chose a light yellow: RGB (248,248,164). I converted to hex: (F8,F8,A4). In TAEdit Properties, I entered 0xF8F8A4. It showed as light cyan.

Please explain.

Auto-sizing in Radio and Checkbox controls would be useful. Default should be False. Put it on the wish list?

I pasted this from the Clipboard (not expecting it to work):

	$testForm = GUICreate("Test Form", $vec[2]-20, $vec[3]-30, $vec[0]+10, $vec[1]+15,$WS_POPUP)
	Local $height = 17
	If IsChecked($chkHorizBar) Then $height = 35
	$t = "Koda"
	GUICtrlCreateInput($t, 8, 8, $vec[3]-16, $height,$gParamStyles,$gParamExStyles)
	GUICtrlCreateLabel("Press Esc key to continue", 8, 80, 164, 40)

and clicked on Process.

I got:

Exception handled 2011-06-19 at 17:41:29 by MainExceptionHandler
Could not convert variant of type (String) into type (Boolean)
Exception Address: 00410E21
Information about Source of Exception
Unit: Variants
Method: HandleConversionException
Line: 0

I expected graceful failure.

The first attached file shows AU3 Import code I pasted. (It is from Date Picker styles with presets suggestion.au3.)

The second shows the result of clicking on Process.

It appears that Koda did not process the GuiCtrlSetData.

It snaps on to one more pixel above my actual client size, making it impossible to not have a scrollbar constantly popping up every time I want to make something as wide as the actual
am not sure if this is a bug or intentional, but it makes koda really hard to use for me.

Using On Event mode, if you add a context menu to an icon there is an error in the code generated. The code for the menus is inserted between the code for the icon and the code for the onclick definition for the icon

$IconBox = GUICtrlCreateIcon("shell32.dll", -10, 748, 223, 34, 34, BitOR($GUI_SS_DEFAULT_ICON,$SS_SUNKEN))
GUICtrlSetResizing(-1, $GUI_DOCKRIGHT+$GUI_DOCKTOP+$GUI_DOCKWIDTH+$GUI_DOCKHEIGHT)
GUICtrlSetTip(-1, "Create a containing rectangle")
$IconBoxcontext = GUICtrlCreateContextMenu($IconBox)
$MenuAskMargins = GUICtrlCreateMenuItem("Always ask for the margins", $IconBoxcontext)
GUICtrlSetOnEvent(-1, "MenuAskMarginsClick")
$MenuFixedMargins = GUICtrlCreateMenuItem("Use the set margins", $IconBoxcontext)
GUICtrlSetOnEvent(-1, "MenuFixedMarginsClick")
$MenuSetMargins = GUICtrlCreateMenuItem("Set the container margins", $IconBoxcontext)
GUICtrlSetOnEvent(-1, "MenuSetMarginsClick")
$MenuRemoveBox = GUICtrlCreateMenuItem("delete the Container", $IconBoxcontext)
GUICtrlSetOnEvent(-1, "MenuRemoveBoxClick")
GUICtrlSetOnEvent(-1, "IconBoxClick") ;<---------------------------------this line should be before CreateContextMenu line

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?

add a option ‘set caption also set name’,set name do nothing with caption.

or add a right menu ‘set caption as form name’ to property list.

         thanks!

I added a listbox, deleted it, and then was adding a combobox. A error window popped up. See
using the latest version. My OS is Windows 7 64bit.

Hello,

I would like to separate the code for generating the form, and my own event code.

One way to do this would be to let Koda generate an au3 file for generating the form, but no event handlers. I would just #include this file in my own au3 file. I am responsible myself for generating the right functions for the event handlers, or I could implement an event loop.

More complex options could be conceived, like in the following post :

   http://www.autoitscript.com/forum/index.php?showtopic=17612

I would be interested in contributing to Koda, and maybe implement this feature myself. I have 10 years of professional programming experience in Borland C++ Builder and Delphi.

Best

While this is cause not too consistent bahaviour (in case of one tab - code generating in one manner, in case of more - fully different), this can be done with only pure Autoit functions. So probably we can give a try.

When added a updown control and enabled UDS_ARROWKEYS style it fails run the
generated code is
<UpdownConstants.au3></code>

When code is generated for the attached .kxf, the #Region line is:

> #Region ### START Koda GUI section ### Form=F:\AutoIt scripts\Koda devel\Styles dialogs\List styles suggestion.kxf

I don’t know how the path got included in this line. I can tell you that I did the following early in developing the List script:

• In Koda, saved the Group script as List styles suggestion.kxf in F:\AutoIt scripts\Koda devel\Styles dialogs
• Changed Group to List in the form, and saved it again
• Saved the Group script as List script
• Changed the #Region line from Group to List
• Exited Koda and ran it again
• Chose Update script

Now Update script complains some of the time when I do Update script.

I know that on one occasion when I had trouble, I had most recently saved F:\AutoIt scripts\Koda devel\Listbox example.kxf. I had exited Koda and had run it again. I then probably opened the List script, then closed Listbox example.kxf. So for a time, forms in 2 different directories were open.

Sorry I can’t be more specific.

Now Update script is working OK. But I note that Generate shows the full path yet only fnam.ext is in the #Region line in the script.

I will try to be more specific when it happens again.

BTW The List form and script are still being designed.