KODA FormDesigner ver 1.3

[KXM]

After a good amout of use with the most recent beta last night, I have two small requests:

1. Option to set a default in a dropdown.

2. Option for blank tag to == no variable assingment.

(IE: I don't need most of my static lables to be assinged to a variable, however if I empty the 'name' field, Koda will genirate code like this:

$ = GuiCtrlCreateLable(...), which needless to say will not work)

None-the-less, THANK YOU for all you hard work, Koda is KILLER!!!

[Lazycat]

@lookfar

Does this mean your are not going to change to XML structure, in order to be able to read this for Access import (or any other XML compliant application) ?

You right. If this will be need, this can be done by import/export.

An here one big question - why you think that format that Access understand will be understandable by "any other XML compliant application"?

Bye the way changing the extention from XML to KXF makes it now impossible to interchange your KODA forms data, with any XML compliant applications. Because they only read by default files with extentions XML.

Impossible? What prevent you from renaming this to XML?

Problem is, that while using XML as extension we can't associate form with program. As you know, many programs (ex. OpenOffice) save their files as XML format, but all have unique extensions that allow run file by just clicking file. Only exception I know - MS InfoPath, but this install wrapper for choosing app in which file will be open.

This means you are moving away from the power of what XML has, is that correct ?

Too loud words. What the power of XML for you? Direct compatibility with Access? Well, imagine that I adapt it to Access. But tomorrow someone would love to make this direct compatible with OpenOffice or something else. How we will solve this problem?

For me, power of XML - exchangeability, so someone can easily take format I did and use my data as he/she want or convert to required format. Now you can take our format and write, say, Au3 script (not too complicated btw) to convert this form to anything you want, for example to standard resource script. Isn't this the goal?

1. Option to set a default in a dropdown.

Do you mean default value in the dropdown box? Setting default by line number is ok?

2. Option for blank tag to == no variable assingment.

(IE: I don't need most of my static lables to be assinged to a variable, however if I empty the 'name' field, Koda will genirate code like this:

$ = GuiCtrlCreateLable(...), which needless to say will not work)

Using empty names is wrong - this will cause form loading error. I think, for labels we can add some field like "NoVariable" with true/false...

[Gene]

A new Koda FormDesigner (Beta) has just been uploaded. which fixes a few issues as well as a few new features have been implemented.

The latest (stable) version is available as well as a Beta preview on the Koda web page.

please note: the default file extension for Forms has been changed, although the XML structure is still the same.

Due to overwhelming demand Koda now reads from the registry certain keys and has the ability to associate the new file extension.

Have Fun!

I do like Koda and you have done a great job in producing it!

That said I also have a few grumbles:

• Since it now reads the registry, I'm surprised that under Options->General->Preview run method it lists the default path to AutoIt.exe instead of the actual path to it which is available in the registry.

• It doesn't matter to me what file name extension you choose, although there do seem to be good reasons for XML. It does matter that the new version of Koda won't open any file saved by the previous versions of Koda, even though you said the data format hadn't changed. No matter what extension you choose, you shouldn't require that extension. An application should be able to open any file of the correct format without regard to the extension.

• I wish you would include a History file with each release, stable or unstable, detailing the changes in feature set have been made as well as what fixes have been made.

• While I'm wishing, I also wish you would increment the version with each release, again stable or unstable. That would help you as well as us, since we could then be sure what version we're writing about, you would also know which version we're writing about.

• For all the menu and toolbar options that are NOT working yet, when clicked or otherwise selected, they should all popup a one or two second dialog saying that the feature/tool/whatever isn't implemented yet!!!!

• Under Options->General->At Startup the 3rd item should be Open File or Open Folder. Allowing the user to select either a specific file to open, or a specific folder for the file open dialog to open in.

Edit: Your point (in another post) about assocaitions is well taken. Edited November 14, 2005 by Gene

[lookfar]

I do like Koda and you have done a great job in producing it!

That said I also have a few grumbles:

1. <snipped grumbles>
   Edit: Your point (in another post) about assocaitions is well taken.1. point taken and duly noted2. it is backwards compatible, just insert *.xml in file open dialog or rename old form.xml to form.kxf
   3. the todo list is on the todo list
   4. stable is 1.3.2.22, beta is 1.3.2.25 (build 25) in file version properties. I suppose this could be also in aboutbox
   5. which are not working for you? (Mainmenu and popmenu are in the works)
   6. beta means beta and feedback is useful, thanks

Edited November 14, 2005 by lookfar

[ptrex]

An here one big question - why you think that format that Access understand will be understandable by "any other XML compliant application"?

Because XML is a universal standard, where all the rules are described how to write and structure it.

Problem is, that while using XML as extension we can't associate form with program.

This is not needed al all. You just have to associate your application for opening XML files.

And for all the rest there is still the OPEN WITH ... functions (right mouse click)

Well, imagine that I adapt it to Access

I am not asking to adapt to Access. This is just an example. I was asking to adapt to a more universal XML coding.

I have more apps than Access. And non of them can read your tags, as it come to structure the data in tables and fields.

[Gene]

1. point taken and duly noted

2. it is backwards compatible, just insert *.xml in file open dialog or rename old form.xml to form.kxf

3. the todo list is on the todo list

4. stable is 1.3.2.22, beta is 1.3.2.25 (build 25) in file version properties. I suppose this could be also in aboutbox

5. which are not working for you? (Mainmenu and popmenu are in the works)

6. beta means beta and feedback is useful, thanks

• ---
• That was the first thing that I tried. Here are error messages: [''Classof65_FIXED.xml'' is not a valid component name.] [''CompileAssistV04.xml'' is not a valid component name.] [''ContactInfo.xml'' is not a valid component name.] These all open OK in the version I was using previously.
• Where is the ToDo list?
• The About Box would be a GREAT place. I use ZipInstall to install these and they all just report 1.3.0.0 internally to the installer. Also when I check their properties in Win Explorer they report 1.3.0.0
• Those you mentioned, plus the Combo Box auto sizes and the height can't be changed until it is in an editor such as Scite. That is important to me because in Win2K Combo Boxes that aren't 100 or more in height don't work. I wish that labels only auto sized once the user turns it on, but I realize that there are probably other opinions too. The last time I went around and tried each menu option and toolbar icon, there were more that didn't work yet, as you note they nearly all do now.

There are grumbles with a smile and those without and those in surprise. Some these were with a smile and some in surprise.

[lookfar]

@ptrex

with all due respect, we are not getting into a pi$$ing contest here.

Koda follows the W3C Extensible Markup Language guidelines.

you can use those guidelines to manipulate the output as you see fit.

Koda is free, you don't have to use it if it does not suit your purpose.

[Lazycat]

Because XML is a universal standard, where all the rules are described how to write and structure it.

Universal, of course. If you check koda form with some xml tidy, you will see that it's format well structured and conform to xml rules (maybe except declaration).

This is not needed al all. You just have to associate your application for opening XML files.

And for all the rest there is still the OPEN WITH ... functions (right mouse click)

This is not needed for you. This is the difference.

And I (and many others) dislike right click method. Ok?

I am not asking to adapt to Access. This is just an example. I was asking to adapt to a more universal XML coding.

I have more apps than Access. And non of them can read your tags, as it come to structure the data in tables and fields.

This was made for Koda, not for some mysterical app. Do you can guarentee that if we make this in Access format you can correctly read this in other apps? I guess, no. But if you can't correctly read this - what the point?

[lookfar]

That was the first thing that I tried. Here are error messages: [''Classof65_FIXED.xml'' is not a valid component name.] [''CompileAssistV04.xml'' is not a valid component name.] [''ContactInfo.xml'' is not a valid component name.] These all open OK in the version I was using previously.

yes you are correct, sorry there is new function that looks for extension and strips it off when opening form,

I will look at another way to do this. so only choice for now is rename old forms.

The About Box would be a GREAT place. I use ZipInstall to install these and they all just report 1.3.0.0 internally to the installer. Also when I check their properties in Win Explorer they report 1.3.0.0

ok that's strange, not so for me, I will insert a version info in aboutbox

Those you mentioned, plus the Combo Box auto sizes and the height can't be changed until it is in an editor such as Scite. That is important to me because in Win2K Combo Boxes that aren't 100 or more in height don't work. I wish that labels only auto sized once the user turns it on, but I realize that there are probably other opinions too. The last time I went around and tried each menu option and toolbar icon, there were more that didn't work yet, as you note they nearly all do now.

the combobox issue is something I have heard about, not running win2k I cannot test but will look into size constraint property for that.

There are grumbles with a smile and those without and those in surprise. Some these were with a smile and some in surprise.

well your really going to be surprised to see what's next!

[lookfar]

the Combo Box auto sizes and the height can't be changed

I just realized the height of a combo box is directly related to it's font.

what does changing the combobox font size do in win2k ?

[Gene]

I just realized the height of a combo box is directly related to it's font.

what does changing the combobox font size do in win2k ?

Well some things happened that I expected, and some that I didn't.

Below is a snippet of the generated code.

$Form1 = GUICreate("AForm1", 622, 444, 193, 122)
$Combo1 = GUICtrlCreateCombo("Gene|Sue|Larry|Moe|curly|Jackson", 150, 40, 181, 116)
GUICtrlSetFont(-1, 54, 400, 0, "MS Sans Serif")
$Label1 = GUICtrlCreateLabel("ALabel1", 380, 250, 164, 20)
GUISetState(@SW_SHOW)

Nothing worked until I commented the font size line, then, the box height being 116 it did dropdown, but only one line. All the items stayed on one line. I rechecked Options->CodeGen and the separator character is in fact the vertical pipe. I tried changing the font too, no help. I thought, I have made a stupid error here, so I copied a ComboBox variable from another script. That didn't work either. It's pasted below.

$Form1 = GUICreate("AForm1", 622, 444, 193, 122)
$sItemList1 = "#Compiler_Allow_Decompile=y|#Compiler_AUT2EXE=|#Compiler_AUTOIT3=|
#Compiler_Compression=4|#Compiler_Icon=|#Compiler_OutFile=|#Compiler_PassPhrase=|#Compiler_Prompt=y|

#Compiler_Res_Comment=Precompile [Compiler Ver. 3.1.1.87]|#Compiler_Res_Description=|
#Compiler_Res_Field=Email |#Compiler_Res_FileVersion_AutoIncrement=y|
#Compiler_Res_Fileversion=|#Compiler_Res_LegalCopyright= |
#Compiler_Run_After=RunAfter.exe "%in%"|#Compiler_Run_AU3Check=n|
#Compiler_Run_Before=CompileAssist.exe %in%"
$Combo1 = GUICtrlCreateCombo($sItemList1, 150, 40, 181, 117)
;GUICtrlSetFont(-1, 54, 400, 0, "Tahoma")
$Label1 = GUICtrlCreateLabel("ALabel1", 380, 250, 164, 20)
GUISetState(@SW_SHOW)

Ideas?

[CatchFish]

CatchFish,

please check your mouse settings:

control panel ->Mouse ->Buttons ->ClickLock (checked/unchecked)

if checked then goto settings and drag to long, or uncheck clicklock completely

The only way I could duplicate your experience was by checking clicklock and setting clicklock to short.

on most systems clicklock is off by default.

Thanky you for your reply!

Everyone feels good while I'm in trouble with no special settings of the Mouse in Control Panel.

I tried KODA in Virtual Machine. The problem is harder to presented, but not impossible.

So...have a nice day.

[Lazycat]

Nothing worked until I commented the font size line, then, the box height being 116 it did dropdown, but only one line. All the items stayed on one line. I rechecked Options->CodeGen and the separator character is in fact the vertical pipe. I tried changing the font too, no help. I thought, I have made a stupid error here, so I copied a ComboBox variable from another script. That didn't work either. It's pasted below.

Ideas?

How about this:

$Form1 = GUICreate("AForm1", 622, 444, 193, 122)
$Combo1 = GUICtrlCreateCombo("", 150, 40, 181, 116)
GUICtrlSetData($Combo1, "Gene|Sue|Larry|Moe|curly|Jackson")
GUICtrlSetFont(-1, 54, 400, 0, "MS Sans Serif")
$Label1 = GUICtrlCreateLabel("ALabel1", 380, 250, 164, 20)
GUISetState(@SW_SHOW)

[ptrex]

@Lazycat

@lookfar

I am not going to arm wrestle with you all about the XML structure. I just wanted to make some suggestions to improve things.

Let me give an other example of how this coudl be used to auto generate forms in AutoIT.

Once the XML stucture would be redefined. We could use the MS XML Com object to read the KODA files.

Pick up the data and generate the form dynamicaly.

But if you all fail to see the beauty of this all. I can' t help.

I did what I thought would be a huge step forward.

Nevertheless KODA is a nice free help for all of us.

[Lazycat]

I am not going to arm wrestle with you all about the XML structure. I just wanted to make some suggestions to improve things.

No prob, suggestions are ok, but this one is a bit late, and your arguments so far not too convincing, that we decide waste month coding and testing. Finally, as I say, import/export is always possible.

Once the XML stucture would be redefined. We could use the MS XML Com object to read the KODA files.

Pick up the data and generate the form dynamicaly.

You want to say that you can't do that now?

Ok, here example how to load koda's form to MSXML object right now and fill tree with controls ierarchy.

load_test.zip

But if you all fail to see the beauty of this all. I can' t help.

I did what I thought would be a huge step forward.

Well, we are fail. Sorry, nobody ideal in this world...

[ptrex]

@Lazycat

Thanks for the reply and the example.

This indead shows the content of the structure, but not the values.

(Can' t get it done in access either when using import/export, only fields but no data in it. Forget access !)

I will try to read the values from the KODA files. But this was just the difficulty in my previous attemps, because of the KODA XML structure.

The music in this is, that if we can pick up the values from the file.

These could be assigned to variables in the GUI script for each position of object.

Once this is working, KODA will be a very dynamic tool !!

If a form is designed and saved in XML format, as it is now, you can just open the tempate again. Move the objects on the KODA grid, and save it.

Open the script again that uses the (changed) XML data (height, width, size, .. etc.). Because it is read dynamically from the KODA files.

You see where I was going to ?

[Lazycat]

This indead shows the content of the structure, but not the values.

This one show values.

expandcollapse popup

$GUI = GUICreate("GUI")
$hTree = GUICtrlCreateTreeView(5, 5, 390, 390)

$oXml = ObjCreate("Msxml2.DOMdocument.3.0")
$oXml.LoadXML(FileRead("AForm2.kxf", FileGetSize("AForm2.kxf")))
$oXmlRoot = $oXml.documentElement
$oFormItem = GUICtrlCreateTreeViewItem("FORM-" & $oXmlRoot.getAttribute("name"), $hTree)
Convert($oXmlRoot, $oFormItem)
GUISetState()


While 1
    $msg = GuiGetMsg()
    Select
    Case $msg = -3
        ExitLoop
    Case Else
    ;;;;;;;
    EndSelect
WEnd


Func Convert($oObjRoot, $hTreeParent)
    For $oGlNode In $oObjRoot.childNodes
        If $oGlNode.nodename = "components" Then 
            For $oNode In $oGlNode.childNodes
                $hTreeItem = GUICtrlCreateTreeViewItem("CTRL-" & $oNode.getAttribute("name"), $hTreeParent)
                Convert($oNode, $hTreeItem)
            Next
        Endif
        If $oGlNode.nodename = "properties" Then 
            For $oNode In $oGlNode.childNodes
                $hTreeItem = GUICtrlCreateTreeViewItem($oNode.getAttribute("name") & "=" & $oNode.Text, $hTreeParent)
            Next
        Endif
    Next
EndFunc

The music in this is, that if we can pick up the values from the file.

These could be assigned to variables in the GUI script for each position of object.

Once this is working, KODA will be a very dynamic tool !!

If a form is designed and saved in XML format, as it is now, you can just open the tempate again. Move the objects on the KODA grid, and save it.

Open the script again that uses the (changed) XML data (height, width, size, .. etc.). Because it is read dynamically from the KODA files.

You see where I was going to ?

Seems I understand, but how you imagine this?

Delphi works in similar way, but it from the beginning support integration with forms, and all control data is keeps in the form. So, when you change, say, height or width, changes only form, not code. In autoit we need to change actual code to things work. Maybe this is possible, but let leave this for version 2.0 or 3.0

[ptrex]

Seems I understand, but how you imagine this?

I am glad with this example which shows the values. How I see this happening is as follows.

At the moment KODA generates XML property data of each control. At the end you can save this to the Clipboard or generate an immediate AU3 script file of it.

Let' s say after you stared added more code to the AU3 GUI script to finish what you started. And you wanted to move some controls or add some. KODA can' t handle the changes at this moment.

Meaning that all the things that change during your project, will have to be manually added or changed (relating to the GUI controls)

With the example we have now running the script can read the property values from the KODA file. So even is changes take place during the project, no problem it is pickup up dynamically. Because it will read the values from the file each time you run the script.

This is stage 1. Where the data is stored in an external file, being KODA.

Stage 2 can be 2 ways.

1 is the XML data is stored in the AU3 script file and read by the XML COM object.

2 is the XML data is stored in a table (like SQLite see script and scraps for the example) and the XML COM can read it from there dynamically for the table.

If I see the time I will try to make an example work using stage 1 as an starting point.

$bTableDyStart = $bTableRYstart + $bTableRheight + $ySpacing
$bTableD = GUICtrlCreateButton("Delete Table", $bTableRxStart, $bTableDyStart, $bTableRwidth, $bTableRheight)
GUICtrlSetOnEvent(-1, "DeleteTable")

Instead of putting the values in the AU3 code hard coded, you can use variables and fill the variables with the data read by the XML COM from the KODA file.

Like you said this might be something for a later release. But once it' s there, it will soeed up flexiblility and performance of the GUI developer.

[KXM]

Do you mean default value in the dropdown box? Setting default by line number is ok?

Yes in a dropdown box, and line number would work very well!

Using empty names is wrong - this will cause form loading error. I think, for labels we can add some field like "NoVariable" with true/false...

I didn't realize no name was an issue. None-the-less 'NoVariable' Sounds great. (Would also be handy in group creation.)

Also, it would be great if we could set the color of controls using a variable name.

IE: I use two globals ($hGUIColorBack & $hGUIColorText) to set all gui items in my script.

This way it's easy to change the color schime for the entire app, with just two lines of code. (Think CSS)

[Gene]

Yes in a dropdown box, and line number would work very well!

I didn't realize no name was an issue. None-the-less 'NoVariable' Sounds great. (Would also be handy in group creation.)

Also, it would be great if we could set the color of controls using a variable name.

IE: I use two globals ($hGUIColorBack & $hGUIColorText) to set all gui items in my script.

This way it's easy to change the color schime for the entire app, with just two lines of code. (Think CSS)

Sort of in this same line of thought, GUIConstants.au3 seems to be missing a number of styles available in Koda. I would not want you to reduce the styles to what is available in GUIConstants.au3. I put an item in the BugList about $LBS_MULTISEL over the weekend. It has had a few views and no responses, I hesitate to speculate on what that means, never the less, it may not be acted on soon.

I wonder if you should post a request enumerating the ones not in GUIConstants.au3, and that they be included in GUIConstants.au3.

or

Should you provide a supplementary list until they can be included in GUIConstants.au3.

or

Just insert them into the generated code as needed.

I have looked on the Internet for a list with values and didn't find it, if you know of such an online list and will give me a list of those you have used, I'll try to produce a list of those not in GUIConstants.au3 for you to review and decide what to do with it.

Edit: spelling

Edited November 15, 2005 by Gene