KODA FormDesigner ver 1.3

[Stumpii]

Great work. I have written a NSIS installer for Koda if anyone is interested. Saves hunting down the KD.exe file all the time.

On an unrelated note, is it possible to have a text box with a variable as the caption instead of a string. I have a form that loads a text box with a value from an INI file when it appears. I don't really want to hack the generated script each time I change it (as I will undoubtedly forget).

[Zedna]

Another idea:

- add support for StatusBar control

I use Label controls with SS_SUNKEN or WS_EX_CLIENTEDGE style as statusbars

So some similar editor as exists for columns in ListView

could be for such statusbar control

composed from labels with SS_SUNKEN or WS_EX_CLIENTEDGE style...

EDIT: it's perfect when there is set GUICtrlSetResizing

to stick it to bottom of main form.

Edited December 6, 2005 by Zedna

[Zedna]

Another issues:

20) when I change form left,top KODA doesn't update modified status

21) when I change form left,top to -1 form should be positioned to centre of screen

or there should be new parameter (as in Delphi) for position of form: Design/Centered

22) name of file where is saved script generated by F10 should be configured in Options

I set in once and now I can't change it

23) Popupmenu for controls: Control/Lock,Unlock,No insert in, No copy

- what it is for?

- when I set No insert in, No copy there should be set checked status in this popupmenu

and changed modified status of form

[Zedna]

I want to say here KODA is GREAT tool

and in today stage it's usable perfect tool

that helps me a lot with design of my AutoIt GUI's.

I must highlight it,

because I posted here a lot of posts about errors, issues etc.

but it's only testing and ideas

in total I'm glad to may use it and help with improving it

It's my courtesy for developers of KODA Form Designer

Edited December 7, 2005 by Zedna

[lookfar]

Another issues:

20) when I change form left,top KODA doesn't update modified status

21) when I change form left,top to -1 form should be positioned to centre of screen

or there should be new parameter (as in Delphi) for position of form: Design/Centered

22) name of file where is saved script generated by F10 should be configured in Options

I set in once and now I can't change it

23) Popupmenu for controls: Control/Lock,Unlock,No insert in, No copy

- what it is for?

- when I set No insert in, No copy there should be set checked status in this popupmenu

and changed modified status of form

20. I will look at that

21. we did have the standard delphi: poDesigned,poDesktopCenter,poScreenCenter etc

as well as numerous other delphi standard properties but slimmed things down to keep it less complicated on us and the user. but your feedback is duly noted..

22. this is just temp.au3 dumped in users %temp% dir, why change it ?

23. control lock will highlite red and cannot be moved, no copy, insert in etc are for your safety in designing forms, you may have things just so and want to lock so your design is not messed up while continuing designing. form is not modified by this behaviour it is simply design tool.

again many thanks for your valuable input and appreciation of our work, after all we are doing this not only for our own enjoyment but also in the hope that it is a useful tool for others.

If you would like to contribute we are in need of a help file...

[Zedna]

22) name of file where is saved script generated by F10 should be configured in Options

I set in once and now I can't change it

22. this is just temp.au3 dumped in users %temp% dir, why change it ?

Sometimes ago I changed this name (after F10 in KODA then in SCITE Save As)

and from this time I can't change this changed name back.

It's only little cosmetics...

***

About contributing to HelpFile:

I'm busy man so whole Help is too big project for me

but part of it will be possible

Just start it, send me frame and example for some functions

and I will continue with it in the same format/style

and will send you back my additions.

You wish to do it in the same style as AutoIt help file?

Like in autoit-docs-v3.1.1-src.exe - in HTML format?

Edited December 8, 2005 by Zedna

[Valik]

I just tried Koda out and have a few issues with it.

• Calling a multi-line edit control a "Memo" is just confusing. Either use "Edit" like AutoIt does or call it a multi-line input control. I was looking for "Edit" or something similar and finally settled on trying "Memo" because that was the only control I'd never heard of.
• What kind of coordinates are the main form in? Do they take into account the full size of the window including the titlebar and border? Everytime I put in the correct width for the client area, some of my controls would get cut off by a few pixels. The only thing I can figure is that your width is from the outside of the border to the outside. This is wrong, the width is for the client-area, only. The borders should not be calculated as part of the width. The titlebar and borders are all part of the non-client area and are added onto the size as specified in a call to CreateWindow(). I expected the width and height I specified in the designer to go straight to the call to GUICreate() but it doesn't.
• The code generated does not obey MustDeclareVars. On the Header/Footer options page, it would be nice to have an option for specifying Global or Local as the scope. It would also be nice to have an option to have the code indented by tabs/spaces.

[lookfar]

I just tried Koda out and have a few issues with it.

• Calling a multi-line edit control a "Memo" is just confusing. Either use "Edit" like AutoIt does or call it a multi-line input control. I was looking for "Edit" or something similar and finally settled on trying "Memo" because that was the only control I'd never heard of.

• What kind of coordinates are the main form in? Do they take into account the full size of the window including the titlebar and border? Everytime I put in the correct width for the client area, some of my controls would get cut off by a few pixels. The only thing I can figure is that your width is from the outside of the border to the outside. This is wrong, the width is for the client-area, only. The borders should not be calculated as part of the width. The titlebar and borders are all part of the non-client area and are added onto the size as specified in a call to CreateWindow(). I expected the width and height I specified in the designer to go straight to the call to GUICreate() but it doesn't.

• The code generated does not obey MustDeclareVars. On the Header/Footer options page, it would be nice to have an option for specifying Global or Local as the scope. It would also be nice to have an option to have the code indented by tabs/spaces.

Koda is written in Delphi and the UI emulates Delphi as best we could, Controls are based off TComponent/TControl which is the Object naming convention of Delphi/C++ Builder. TAEdit is a custom written control that inherites from TMemo which is the standard Delphi small strings editor.

If you load a standard form in Koda and hit F9, see the code as "622, 448, 192, 125"

and in Object Inspector the width is 640, Height is 475, this takes into account the client area, Is this not correct?

If changing width or height (or any value for that matter) in Object Inspector, One must click somewhere in the Object Inspector after the modification or hit enter to qualify the change.

Yes I agree that variables need to be configurable as local or Global, A new build is forthcoming that will have a few more features like HiddenClasses (MainMenu, PopupMenu and common Dialogs) and multilanguage support. More configurable code output is also planned.

Thanks for you feedback

[Valik]

Koda is written in Delphi and the UI emulates Delphi as best we could, Controls are based off TComponent/TControl which is the Object naming convention of Delphi/C++ Builder. TAEdit is a custom written control that inherites from TMemo which is the standard Delphi small strings editor.

The controls AutoIt uses are not Delphi controls, they are standard Win32 controls. Naming them after Delphi controls when that is not what they are is confusing.

If you load a standard form in Koda and hit F9, see the code as "622, 448, 192, 125"

and in Object Inspector the width is 640, Height is 475, this takes into account the client area, Is this not correct?

It should only take into account the client area. The border and titlebar are part of the non-client area. When I enter 640 into the Object Inspector, I expect the client area to be 640, not the total GUI size (The total GUI width would be 640 + (border * 2)). The non-client area is theme dependent. On Windows XP, 3 different configurations could have 3 different border sizes. Koda should only concern itself with setting the size of the client area, otherwise the size of the client area will be different by a few pixels on different configurations.

[LondonNDIB]

Agreed... that was what I was coming here to say. What I define as the client area should be what I get!

Huge reason for this is that it messes up any controls you try to place at the bottom (keeps moving them up)... but mostly so that you get expected results.

Same for the tabs. In AutoIt, I specify the relation of my control to the edge of the client area, not the edge of the tabspace - but in Koda I have to specify in relation to the edge of the tabspace. Just keep it simple and consistent with AutoIt... my suggestion anyway.

Some other issues:

1) Seems that I can not specify any styles or exstyles for any control. I can click the tabs, but there are no options at all to choose. Is this just me? If I were you, I wouldn't even bother necessarily to make sure they are all there - but let the user manually specify the value!

2) It would be nice if when I named a control... ANY control... that the resulting code would begin with "$name =" like it does when you name a button, form, list, etc. Should do the same with labels and whatever else too because they ARE controls and not necessarily static.

Keep in mind this tool isn't only for generating a GUI once... there will always be trial and error. As it currently is, I use Koda to generate code then I have to manually edit the code for styles and naming (two points above) and then if there is something I want to change graphically I have to re-generate the code and re-do ALL the changes I manually performed. It would be great if you could allow the flexibility that would let a user do all the fine-tuning of the code they might find necessary right from Koda.

Great tool!

LD

[lookfar]

@LondonDib

Forms : the Form size client size will be addressed in next build.

Tabs : Because Koda uses Object Oriented controls the child controls will inherite from the parent. AutoIt is not Object Oriented so, calculating and conversion will take place to compensate for this difference. You will not or will not ever see the Autoit co-ordinates in object inspector for child controls it simply will not work that way.

1. You should have a file called "styles.xml" in the Koda Directory that is 28kb, If not re-download. You should be able to adjust Styles and ExtStyles on the fly and see the changes visually.

2. They do..you must have a bad install or file corruption.

your last point should be resolved with a correctly functioning Koda application.

Edited January 11, 2006 by lookfar

[Rex]

Hi when i removes the ticks in Minimizebox but keeps in caption and sysmenu. koda don't put it in the code, in the design it looks fine dut the generated code contains only GUICreate(" Aform1", 213, 289, 363, 327) but where is my caption+sysmenu ??

Is this a bug or is it just me there can't finde out to use Koda ???

btw nice work, only thin we now miss is the ability to work with codes inside koda

/Rex

[LondonNDIB]

@LondonDib

Forms : the Form size client size will be addressed in next build.

Tabs : Because Koda uses Object Oriented controls the child controls will inherite from the parent. AutoIt is not Object Oriented so, calculating and conversion will take place to compensate for this difference. You will not or will not ever see the Autoit co-ordinates in object inspector for child controls it simply will not work that way.

1. You should have a file called "styles.xml" in the Koda Directory that is 28kb, If not re-download. You should be able to adjust Styles and ExtStyles on the fly and see the changes visually.

2. They do..you must have a bad install or file corruption.

your last point should be resolved with a correctly functioning Koda application.

You were correct! I reinstalled and it works now! I'm not sure what happened there. Thanks!

[1of10]

First thing I want to get out of the way is that I can't thank the coding Gurus, LazyCat and lookfar, enough for this remarkable AutoIt tool! I was putting off developing a lot of pointless GUIs simply because I didn't like the functionality of the existing GUI Builder, and didn't want to put in the effort to write the GUIs by hand. Yeah, I'm lazy...

And now, for what I've discovered with the latest version of Koda, that comes packaged with SciTe4AutoIt3 v3.1.1.102... You may need to refer to one or more provided full screen capture(s), which will be uncompressed BMP, in order to maintain quality and clarity. As a result of the file sizes, the captures are stored on my own server -- it will be slow at times -- and linked here.

• Reference capture: KodaViaSciTe_LoadForm-110QH.bmp / 2.85MB / 1152x864x24bpp
  • Command Line option "/Scite" passed to Koda when launched within SciTe. I gather this option tells Koda to paste into SciTe when selecting the Generate Code menu item, as opposed to just copying to the clipboard. When loading Koda this way, I can create a new form from Template -- LOVE the Gallery, BTW -- but I cannot File / Open an existing form or template. I get the error shown in the capture: "/Scite" is not a valid component name.
  • Shown in the capture is everything mentioned above:
  • AForm1, which is the default form opened when Koda opened.
  • AForm2, which is the new form from template, DualListDlg.
  • Error MsgBox, when I attempted to File / Open the AboutBox.kxf from the Templates directory.
• Reference capture: KodaViaCmd_NotDefaultStyle-110QH.bmp / 1.27MB / 861x517x24bpp
  • This is a rather quirky issue with the style attributes. I've found that un-checking certain boxes causes other boxes to automatically un-check. I presume this is to avoid conflict of incompatible attributes when a prerequisite is no longer selected. I'm not sure if this is an "undocumented feature," but those same linked boxes do not automatically re-check when I re-check the box that initially turned the linked ones off. (I hope you followed that... I almost lost myself while typing it. )
  • Another style attribute issue, or "undocumented feature," is related to generating the code. In the referenced capture, I have highlighted the WS_MINIMIZEBOX attribute in the Object Inspector. It took me a LONG time to figure out how to get that one to actually turn off, because, what I failed to notice each time I generated the code was that the styles position in the GuiCreate() is set to default (-1). I had to fiddle around until I found the right combination of attributes on and off that actually put something into that position -- the position, by the way, is highlighted in the code window. Maybe this is just my lack of understanding of the required links between attributes...
• I have also experienced the really fast click-and-accidentally-drag issue, mentioned about five pages, and several revisions, back in this thread.
• I've also had X,Y,W,H values change on me, without a click-drag, and without locking a control in place. Some of the controls seem to be permanently bound to the data, or contents, the control contains. In other words, a drop-down is a thin sliver horizontal line, because it has no content -- I was going to assign this later in my script, rather than the form itself. This, too, could be my lack of experience with GUI authoring tools...
• This true bug, which is also shown in the code window of KodaViaCmd_NotDefaultStyle-110QH.bmp, is the line that shows GUISetColor(0xFFFFFF). While testing the form shown in that capture, I had to comment-out or remove the GUISetColor() line, because it is not a valid AutoIt3 function. I don't know if it exists in the v3.1.1.0 release version, or if it was a briefly lived Beta function, but it does not exist in v3.1.1.103.
• Last, but not least, is a recommendation for the Templates Gallery view: larger samples of the forms. the current samples size is a little too small to make out what the form contains, at least on a screen resolution of 1152x864.

Relevant details of my environment:

• AutoIt3 v3.1.1.0 and v3.1.1.103 (Beta) -- I usually develop in Beta.
• Koda v1.4.2.4 (WinPE FileVersion Tag) / v1.4.0 (Koda's own About Box)
• Windows 2000 Professional CSD0400 (more commonly known as Service Pack 4, via Windows Update)
• English language (en-CA/en)
• All related software installed under D:\AutoIt3 -- No spaces anywhere in any paths
  • D:\AutoIt3
  • D:\AutoIt3\BETA
  • D:\AutoIt3\SciTe
  • D:\AutoIt3\SciTe\Koda
• All of my project/work files, including my own Koda forms, are stored in a similar path-style:
  • D:\PRJ\PROG\AUT
  • D:\PRJ\PROG\AUT\KodaForms

Oh, and if you need some help with any part of the development of Koda, be it Compiled HTML Help generation, additional coding assistance, pre-release-beta testing, etc., I'd be glad to help in any way I can.

Looking forward to the next release, of Koda and AutoIt3...

[Valik]

Why don't you just post the screenshots as PNG's? It's a lossless format and the file sizes will only be a faction of what they are as BMP.

[Zedna]

Another idea:

- add support for StatusBar control

I use Label controls with SS_SUNKEN or WS_EX_CLIENTEDGE style as statusbars

Idea reloaded

Now when in AutoIt Beta include directory is new GuiStatusBar.au3

I think it's best time to implement this kind of StatusBar also in KODA

--

also look at my Czech language file for KODA here

[Lazycat]

Now when in AutoIt Beta include directory is new GuiStatusBar.au3

I think it's best time to implement this kind of StatusBar also in KODA

Ok, probably this can be done when GuiStatusBar.au3 will be finally fixed and accepted.

[Zedna]

Ok, probably this can be done when GuiStatusBar.au3 will be finally fixed and accepted.

I'm missng this functionality little bit,

so I'm looking forward to new KODA with StatusBar if it becomes.

But no big problem for me, I can live without it so far.