GUI Designer: Koda 1.7.3.0

[Lazycat]

I loaded a design and the form name was changed from Form1 to Form1_1 and I couldn't changed the name back. Then I realised that there was another form alreday called Form1 underneath. Maybe you should give an option to not load another form with a duplicate name? But it's a small point.

Agree, now I don't like this behaviour too and think this is wrong. Now Koda check only if form with the same filename already opened. If in designer exists form with the same actual form name, new form become renamed. I think I'll change it.

EDIT: Oh, and F10 now brings up explorer opened at the folder containg Koda.

For me it work as expected... this code not changed in any way.

[martin]

Agree, now I don't like this behaviour too and think this is wrong. Now Koda check only if form with the same filename already opened. If in designer exists form with the same actual form name, new form become renamed. I think I'll change it.

For me it work as expected... this code not changed in any way.

The problem is with the FD.XML file. If you run the download in the link in your post of 24th September the FD.XML file created does not have a line for <lastformpath></lastformpath>

and even if you select the option to open the last form on startup it does not appear and you always start with a new Form1.

If you close Koda, add the missing line in the configuration, global section then Koda once again works as it should.

So the mistake I made was to unzip the files into a new folder. Tested Koda in the new folder and then copied all the files to my usual folder, but I should not have copied the FD.XML file.

I think it's a little bug with creating/writing the FD.XML file.

Edited September 26, 2008 by martin

[Valik]

I wanted to create a master form with several embedded child forms (A form with $WS_CHILD and a parent). I couldn't do this natively. Either it's really hidden or just not possible without hacking. I had to edit styles.xml and remove managed="true" from the WS_CHILD style on TAForm. That allows me to set WS_CHILD on the forms I wanted to be embedded. My question is, why do I have to do this in order to do something AutoIt fully supports?

Edit: Another complaint, why the hell does the position you edit the form have anything to do with where the form appears when you run the script? It's pretty stupid that in order for me to have this embedded GUI positioned at 0,0 in the parent form I also have to edit it at 0,0 on my Desktop. Koda arbitrarily couples the editing with the positioning and it's just retarded and annoying.

Edit 2: Even more retarded, I specifically hard-coded the left/top position to 0 but Koda refuses to actually use this value when generating code, it insists on using 1,1. Please write your application to give me the benefit of the doubt I'm not an idiot and do what I tell it to, not what it wants to.

Edited September 28, 2008 by Valik

[Lazycat]

I wanted to create a master form with several embedded child forms (A form with $WS_CHILD and a parent). I couldn't do this natively. Either it's really hidden or just not possible without hacking. I had to edit styles.xml and remove managed="true" from the WS_CHILD style on TAForm. That allows me to set WS_CHILD on the forms I wanted to be embedded. My question is, why do I have to do this in order to do something AutoIt fully supports?

When it was done, Koda even has no parent property for the form. I was not need using child forms yet, nor someone else reported it too.

Edit: Another complaint, why the hell does the position you edit the form have anything to do with where the form appears when you run the script? It's pretty stupid that in order for me to have this embedded GUI positioned at 0,0 in the parent form I also have to edit it at 0,0 on my Desktop. Koda arbitrarily couples the editing with the positioning and it's just retarded and annoying.

Stupid this or not, for Borland products this is standard behaviour. This can be changed for Koda, but since form here is "floating" (instead VS), I feel that using independent positioning will just mess users. If here is any way to non-messing workaround - suggestions are welcome.

Edit 2: Even more retarded, I specifically hard-coded the left/top position to 0 but Koda refuses to actually use this value when generating code, it insists on using 1,1. Please write your application to give me the benefit of the doubt I'm not an idiot and do what I tell it to, not what it wants to.

Every program have bugs - this is the axiom. If every bug in every program I use would irritate me so, I would go crazy already...

Hundreds people are using Koda, only few make regular effort to report bugs and make suggestions. Reported bugs are always fixed when it's possible. Definitely, unreported ones may stay for a very long time (like this). Well, looks like you first who tried to make child forms in Koda and first who noticed problem with 0,0 position. Congratulations.

[Valik]

Stupid this or not, for Borland products this is standard behaviour. This can be changed for Koda, but since form here is "floating" (instead VS), I feel that using independent positioning will just mess users. If here is any way to non-messing workaround - suggestions are welcome.

It's really very simple, a new Position setting like "poFixed" which when set allows the form to be dragged around the Desktop so it can be edited wherever but it does not update the Left and Top variables. The Width/Height should still change if the form is resized.

Every program have bugs - this is the axiom. If every bug in every program I use would irritate me so, I would go crazy already...

Hundreds people are using Koda, only few make regular effort to report bugs and make suggestions. Reported bugs are always fixed when it's possible. Definitely, unreported ones may stay for a very long time (like this). Well, looks like you first who tried to make child forms in Koda and first who noticed problem with 0,0 position. Congratulations.

Actually no, the 0,0 position bug appears to be affecting every single user of Koda. I just noticed that the width, height and position of a form is actually +1 what it shows in Koda. Size a form to 100, 100 and use poDesigned to set the position somewhere, then use Generate Form Code. Notice that the width and height is now 101 for both and that the position is also offset by 1.

Why are there two width and two height properties? AutoIt works only in client sizes so it seems that the full width/height properties are pointless and confusing. It's also a bad idea to provide them because the people using them are really only using a machine-specific way to set the client size since the moment a different them is used the size is likely to change. Seems confusing - is it really needed?

[Lazycat]

It's really very simple, a new Position setting like "poFixed" which when set allows the form to be dragged around the Desktop so it can be edited wherever but it does not update the Left and Top variables. The Width/Height should still change if the form is resized.

Good idea, and this will not break existing forms.

Actually no, the 0,0 position bug appears to be affecting every single user of Koda. I just noticed that the width, height and position of a form is actually +1 what it shows in Koda. Size a form to 100, 100 and use poDesigned to set the position somewhere, then use Generate Form Code. Notice that the width and height is now 101 for both and that the position is also offset by 1.

Why are there two width and two height properties? AutoIt works only in client sizes so it seems that the full width/height properties are pointless and confusing. It's also a bad idea to provide them because the people using them are really only using a machine-specific way to set the client size since the moment a different them is used the size is likely to change. Seems confusing - is it really needed?

Agree, I did the tests as well and come to the same result: here errorously added border width to the actual dimensions. I also agree, that in this case two pairs of properties are redundant. I'll look if this will not break existing forms or at least can be fixed automatically.

[Lazycat]

New beta is out.

http://www.autoitscript.com/fileman/users/lookfar/koda_2008-10-03.zip

Here fully rewritten Picture Editor dialog, now it support choosing icons with multiple sizes subicons and correctly show hi-color icons. Icon control rewritten too, now support setting custom control size and have behaviour exactly as in Autoit. As well changed all other controls that load icons (Form and Button). Button now can show coloring (and retain it's Autoit behaviour).

Also added poFixed mode for forms, where generated position of form not depend on form screen position.

Note for this release: due changes made in the Picture Editor (and previous changes in graphic controls resource loading), in forms where you have set custom pucture path you will not see image. To fix this problem open Picture Editor, note your custom path in edit field and click "Test" button. If Koda will be able to expand your string, you will see image or icon loaded. After that just click Ok and save form (now custom path will be saved in separate property).

[Zedna]

I have problems with default style at Button control.

In styles.xml is 

  <class name="TAButton" default="50010000">

  <style name="BS_PUSHBUTTON" value="00000000" mask="1"/>

  <style name="BS_DEFPUSHBUTTON" value="00000001" mask="1"/>

  <style name="BS_PUSHBOX" value="0000000A"/>

  <style name="BS_LEFT" value="00000100" mask="00000300"/>

  <style name="BS_RIGHT" value="00000200" mask="00000300"/>

  <style name="BS_CENTER" value="00000300" mask="00000300"/>

  <style name="BS_TOP" value="00000400" mask="00000C00"/>

  <style name="BS_BOTTOM" value="00000800" mask="00000C00"/>

  <style name="BS_VCENTER" value="00000C00" mask="00000C00"/>

  <style name="BS_PUSHLIKE" value="00001000"/>

  <style name="BS_MULTILINE" value="00002000"/>

  <style name="BS_NOTIFY" value="00004000" forced="1"/>

  <style name="BS_FLAT" value="00008000"/>

  <style name="BS_ICON" value="00000040" managed="true"/>

  <style name="BS_BITMAP" value="00000080" managed="true"/>

  <style name="WS_OVERLAPPED" value="00000000"/>

  <style name="WS_GROUP" value="00020000"/>

  <style name="WS_TABSTOP" value="00010000" forced="1"/>

  <style name="WS_HSCROLL" value="00100000"/>

  <style name="WS_VSCROLL" value="00200000"/>

  <style name="WS_VISIBLE" value="10000000" forced="true"/>

  <style name="WS_CHILD" value="40000000" mask="80000000" forced="true"/>

  <style name="WS_BORDER" value="00800000"/>

  <style name="WS_CLIPSIBLINGS" value="04000000"/>

but everytime I place new button on the form it has BS_FLAT style and I must change it by hand (switch off BS_FLAT).

generated code is

$MyButton1 = GUICtrlCreateButton("MyButton1", 376, 80, 100, 30, $BS_FLAT)

corrected code:

$MyButton1 = GUICtrlCreateButton("MyButton1", 376, 80, 100, 30, 0)

[Zedna]

New beta is out.

http://www.autoitscript.com/fileman/users/lookfar/koda_2008-10-03.zip

There is still "old bug" with bad order of controls in code generator:

If you place main menu and statusbar control (and others) on the form

then menu must be first and statusbar last (statusbar must be AFTER menu - not before).

Described here:

http://www.autoitscript.com/forum/index.ph...st&p=574087

Place main menu, toolbar and statusbar on the form.

After you run generated code you will not see statusbar.

[Zedna]

ImageList Editor:

When you use EXE file which is running (for example fd.exe) AV occurs.

Cannot open file "C:\Program Files\AutoIt3\SciTE\Koda\FD.exe". The process can not work with the file,

because it is used by another process

Exception Address: 0041FA6A

Information about Source of Exception

Unit: Classes

Method: TFileStream.Create

Line: 0

I think you can open this file in read (shared) mode to avoid this.

Edited October 4, 2008 by Zedna

[Lazycat]

I have problems with default style at Button control.

...

but everytime I place new button on the form it has BS_FLAT style and I must change it by hand (switch off BS_FLAT).

I revised this, but not found problems. Maybe you have file control_templates.xml accidentally placed in Koda folder?

There is still "old bug" with bad order of controls in code generator:

Yeah, forget, though this important enough. You may download quick test version, with changes made in code generator. Here menu and all context menus generating right after their controls.

ImageList Editor:

When you use EXE file which is running (for example fd.exe) AV occurs.

I think you can open this file in read (shared) mode to avoid this.

They open with fmOpenRead and fmShareDenyWrite flags. This not cause problems for me, at least I'm not got this error on running FD.exe

[Zedna]

I revised this, but not found problems. Maybe you have file control_templates.xml accidentally placed in Koda folder?

Yes. There is control_templates.xml in standard Koda package:

koda_2008-10-03.zip

"c:\Program Files\AutoIt3\SciTE\Koda\Extras\Control Templates\control_templates.xml"

<control_templates>
  <object type="TAForm">
  <properties>
    <property name="Width" vt="Int8">600</property>
  </properties>
  <components/>
  </object>

  <object type="TAButton" name="MyButton%INSTANCE%">
  <properties>
    <property name="Width" vt="Int8">100</property>
    <property name="Height" vt="Int8">30</property>
    <property name="CtrlStyle" vt="Int32">1342291968</property>
  </properties>
  <components/>
  </object>
</control_templates>

When I removed this file it's OK.

Yeah, forget, though this important enough. You may download quick test version, with changes made in code generator. Here menu and all context menus generating right after their controls.

This version is OK.

They open with fmOpenRead and fmShareDenyWrite flags. This not cause problems for me, at least I'm not got this error on running FD.exe

I tested this only on WIN98SE for now.

[Zedna]

Picture Editor:

When I change icon in "Images in file" by keyboard (Up/Down) instead of mouse clicks

then "Selected image" content is not refreshed.

[Lazycat]

Picture Editor:

When I change icon in "Images in file" by keyboard (Up/Down) instead of mouse clicks

then "Selected image" content is not refreshed.

Really stupid bug, this should be called "make simple thing in weird way"... Thanks, fixed for next beta.

[Cdma1X]

i can not rename a checkbox in Koda because it uses it as a variable and i can not give space between it.

see if i will create a check box then by default it will create it like this.

$Checkbox1 = GUICtrlCreateCheckbox("Checkbox1", 24, 24, 97, 17)oÝ÷ Ù»­Â§·§jg¬¶ç$nbJjØ^'z-+ÞjÊZqì!W«zv¦x"¶+wöÆÞq«¬zØ^±©½ªâi¹^©Ë¬yÜ!zzÞ©¢§vö«¦åzÇhmjYhÂÊZqæÞ·Ø^ǧ¶Ú+zv¦z+m¢«¨¶Øb²+-zËjº[ºØ­r·µëºÚ"µÍÌÍÝÈHÕRPÝÜX]PÚXÚØÞ
    ][ÝÝÉ][ÝËMËMÊ

why is this? or is it a bug?

[Lazycat]

i can not rename a checkbox in Koda because it uses it as a variable and i can not give space between it.

see if i will create a check box then by default it will create it like this.

why is this? or is it a bug?

Hm, variables in the Autoit are really allow spaces? In Koda, control name become variable. Variables can use only latin letters, digits and underscore (except arrays which Koda currently not supported), control names the same. Also name for control can be empty, in this case variable will not generate (primarily useful for labels).

If you want change text of control - use "Caption" property.

[Valik]

LazyCat, the problem here (and it annoys me too) is that the name of the control as displayed in the Object TreeView is the same as the variable name. There are many controls that I want to identify with a descriptive name (in the designer) but don't need to generate a variable for. However, in order to prevent variable generation I'm stuck with the designer forcing a terribly unhelpful name on me.

For example, imagine I have a form with a few GroupBox controls on it. Naturally I do not need variables for those boxes. But I would like to have names for them in the Object TreeView so I can quickly identify which group I want work with. So my choice becomes, do I want design-time names and run-time variables I don't need? Or do I want to avoid the useless run-time variables but have useless design-time names making it harder to identify which control I'm working with?

My opinion on the subject is that Koda is confusing data and display here. It's providing what initially appears to be display-only information about the hierarchy of controls with useful and recognizable names but in reality it's just displaying data that may not be required for every control. It forces users into a choice of "design convenience or run-time efficiency".

My suggestion is to remove the coupling between the "Name" property and the display in the Object TreeView. Change the property from "Name" to "Variable" and then allow conventional in-line editing of the TreeView for renaming objects. The naming is purely cosmetic and is only useful for making designing easier. If there is no explicit value set in the TreeView then it's fine to continue using the Name/Variable property but we should be allowed to override it in the Object TreeView, especially in cases where we don't want to generate a Variable at all.

[Zedna]

I think it should be mix of current and Valik proposed behaviour:

- use variable names and if there is Text/Caption property then use this property (if it's not empty)

[Lazycat]

Glad to see some good suggestions here.

I though and agree, that some descriptive names would be good.

At the moment the simplest solution is what Zedna suggested - using caption for identity controls. But here the problem that only few controls have this property, and for, say, combobox, you still will see just a name.

What Valik suggested is more complete, but have a problems in technical plane. I don't think it's technically possible to use "Name" property for some descriptive comment (at least without rewriting almost all), since it's name of objects which are used for setting relations between objects. But I already though before about using separate "Variable" property for variable name instead of object name in order to allow using array variables. In this case "Name" can be for internal use only and hidden.

Also this cause issue with "attaching" one control to another (Menu, Updown etc) since there used names as well, this need to be solved too.

I will think how to make descriptions with small losses; showing captions looks simple and can be done with no loss.

[martin]

AutoIt works only in client sizes so it seems that the full width/height properties are pointless and confusing. It's also a bad idea to provide them because the people using them are really only using a machine-specific way to set the client size since the moment a different them is used the size is likely to change.

That is incorrect.

If you create a window and specify a width and a height then the help incorrectly says that the window will have that height and that width. In any case the client dimensions depend on the styles used and might not be the dimensions specified. This confuses many people including me.

This post by maikelmayers demonstrates.