GUI Designer: Koda 1.7.3.0

[zorglub]

This would be good addition, but unfortunately no simple way. Koda is Delphi based thing and follow it's rules, some of them can't be bypassed directly. In this case, control name can contain only a-z, digits and underscore. Now you can use arrays in any text properties (%var1[$var2]% and set expand variables option for form), but not for control names.

Would it be possible to add a new option to substitute a string by another string when koda generates/imports the form code:

in Koda, options:

_PO_ = "["

_PD_ = "[$"

_PC_ = "]"

in Koda, checkbox name:

GUIArray_PD_IDCHECKNIGHT_PC_

Those substitution strings could even be user definable to be compatible with every script.

Not pretty, but it may work

[Lazycat]

Not pretty

Yeah, I alredy think about it, but quoted sentence is the reason of doubts Especially because this inconsistent with other substitutes.

[JohnBailey]

Possible Bug:

When I double click on a control and attempt to select NONE for event name, no matter what file I open it will revert back instantly to the name radio. Why?

[Lazycat]

Possible Bug:

When I double click on a control and attempt to select NONE for event name, no matter what file I open it will revert back instantly to the name radio. Why?

This is by design No, this is not revert actually, if after applying "none" you select control again and look for example for "onclick" property - you will see it's empty. Koda always "suggest" notify option, since usually you open this dialog to enable event and this save you from redundant clicking.

Maybe this will be less messing, if add in this dialog some label with current event state?

[JohnBailey]

This is by design No, this is not revert actually, if after applying "none" you select control again and look for example for "onclick" property - you will see it's empty. Koda always "suggest" notify option, since usually you open this dialog to enable event and this save you from redundant clicking.

Maybe this will be less messing, if add in this dialog some label with current event state?

OH! That makes sense

Yeah, the label would be helpful for goobers like me.

EDIT

Actually it doesn't seem to not use an onclick property see below:

$Form1 = GUICreate("Daily Downloader", 567, 708, 193, 125)
GUISetOnEvent($GUI_EVENT_CLOSE, "Form1Close")
GUISetOnEvent($GUI_EVENT_MINIMIZE, "Form1Minimize")
GUISetOnEvent($GUI_EVENT_MAXIMIZE, "Form1Maximize")
GUISetOnEvent($GUI_EVENT_RESTORE, "Form1Restore")
$LV_Main = GUICtrlCreateListView("Account Name|Account Number|Folder Name", 33, 173, 495, 461)
GUICtrlSendMsg($LV_Main, 0x101E, 0, 200)
GUICtrlSendMsg($LV_Main, 0x101E, 1, 100)
GUICtrlSendMsg($LV_Main, 0x101E, 2, 180)
GUICtrlSetOnEvent($LV_Main, "LV_MainClick")
$Label2 = GUICtrlCreateLabel("", 105, 94, 340, 30, $SS_CENTER)
GUICtrlSetOnEvent($Label2, "Label2Click")
$progressbar2 = GUICtrlCreateProgress(196, 124, 150, 12)
$progressbar1 = GUICtrlCreateProgress(196, 134, 150, 17)
$Run_Act_BTN = GUICtrlCreateButton("Act", 137, 18, 78, 25, 0)
GUICtrlSetOnEvent($Run_Act_BTN, "Run_Act_BTNClick")
$Run_Inv_BTN = GUICtrlCreateButton("Inv", 221, 18, 78, 25, 0)
GUICtrlSetOnEvent($Run_Inv_BTN, "Run_Inv_BTNClick")
$Run_Both_BTN = GUICtrlCreateButton("Both", 324, 19, 78, 25, 0)
GUICtrlSetOnEvent($Run_Both_BTN, "Run_Both_BTNClick")
$StatusBar_LB = GUICtrlCreateLabel("", 0, 666, 565, 21, BitOR($SS_CENTER,$SS_CENTERIMAGE,$SS_SUNKEN))
GUICtrlSetOnEvent($StatusBar_LB, "StatusBar_LBClick")
$MenuItem1 = GUICtrlCreateMenu("IE Tools")
GUICtrlSetOnEvent($MenuItem1, "MenuItem1Click")
$MenuItem2 = GUICtrlCreateMenu("All IE Objects", $MenuItem1)
GUICtrlSetOnEvent($MenuItem2, "MenuItem2Click")
$MenuItem4 = GUICtrlCreateMenuItem("Show", $MenuItem2)
GUICtrlSetOnEvent($MenuItem4, "MenuItem4Click")
$MenuItem3 = GUICtrlCreateMenuItem("Close", $MenuItem2)
GUICtrlSetOnEvent($MenuItem3, "MenuItem3Click")
GUISetState(@SW_SHOW)

I've set all the controls to none except the btns and the gui window itself.

Edited October 31, 2007 by JohnBailey

[Lazycat]

OH! That makes sense

Yeah, the label would be helpful for goobers like me.

Added

EDIT

Actually it doesn't seem to not use an onclick property see below:

...

I've set all the controls to none except the btns and the gui window itself.

Ensure that you have not checked option "generate events for all controls". Looks like this set, and override all events you cleared before...

[JohnBailey]

Added

SWEET!

Ensure that you have not checked option "generate events for all controls". Looks like this set, and override all events you cleared before...

OH!!! That's totally what I was doing. So I need to set each one manually? Hmm, that can be cumbersome for projects that have a lot of controls. Oh well for me.

[Lazycat]

OH!!! That's totally what I was doing. So I need to set each one manually? Hmm, that can be cumbersome for projects that have a lot of controls. Oh well for me.

Yeah, but here is a trick that can make life easier: select few controls with same event (for example onclick) and in the Property Inspector set this event. It will be applied to all selected controls.

[JohnBailey]

Yeah, but here is a trick that can make life easier: select few controls with same event (for example onclick) and in the Property Inspector set this event. It will be applied to all selected controls.

oh again I had no idea Thanks!

[Guest BillBeavis]

I've been using Koda for a couple things and it is very helpful. I have two things I'd like to see, and I realize they may be significant.

1. There is a one way relationship from Koda to the AutoIt script. It would be nice to read changes from the script back into Koda, to update it. This kind of relates to opening a non-Koda .au3 file and converting it. Here is a situation. I create a button and give it a generic function for onclick, since I have yet to do the coding. While coding, I set the function name. I then have to open Koda and re-set the function to the new on I created, then update script. It would be nice if I could modify the code for Koda and just update the function call. Yeah, it violates the don't change between the lines. I also realize that it creates a huge headache in maintaining the code. I'm just whining about having to do extra steps, but there should be a way to update in the other direction. If nothing else, you could compare the kxf to what is read from the au3 and then scream at the programmer for touching it. The next step would be to ask to use the new or revert to old. etc etc. Open for discussion. Along this lines, it would be nice to open an existing au3 file and convert to koda. Certainly not a simple task, I'm sure many have requested it and you probably are even working on it.

2. Not a Koda issue but scite. When in scite, I select tools and koda. I modfiy the gui to my hearts content. But I have to exit koda to test it. Scite tools are locked out. I'm probably doing things a**backwards, but here is what I do. open the au3 in scite. in scite go to tools and koda. close form1 that koda insists on starting (instead of reading the au3 I have open), then open the au3 file in koda, then make my change, then save (otherwise the kxf and script seem out of sync), then update script, then exit koda, and finally tools and go (rinse and repeat). Tighter integration would be nice. I suppose I could open koda outside of scite. don't know. Currently it's not a terrible burden.

[JohnBailey]

I've been using Koda for a couple things and it is very helpful. I have two things I'd like to see, and I realize they may be significant.

1. There is a one way relationship from Koda to the AutoIt script. It would be nice to read changes from the script back into Koda, to update it. This kind of relates to opening a non-Koda .au3 file and converting it. Here is a situation. I create a button and give it a generic function for onclick, since I have yet to do the coding. While coding, I set the function name. I then have to open Koda and re-set the function to the new on I created, then update script. It would be nice if I could modify the code for Koda and just update the function call. Yeah, it violates the don't change between the lines. I also realize that it creates a huge headache in maintaining the code. I'm just whining about having to do extra steps, but there should be a way to update in the other direction. If nothing else, you could compare the kxf to what is read from the au3 and then scream at the programmer for touching it. The next step would be to ask to use the new or revert to old. etc etc. Open for discussion. Along this lines, it would be nice to open an existing au3 file and convert to koda. Certainly not a simple task, I'm sure many have requested it and you probably are even working on it.

This isn't exactly what you're talking about, but have you used import? "Along this lines, it would be nice to open an existing au3 file and convert to koda." - that is exactly import, unless I misunderstood you.

[Zedna]

This isn't exactly what you're talking about, but have you used import? "Along this lines, it would be nice to open an existing au3 file and convert to koda." - that is exactly import, unless I misunderstood you.

Just for clarification: In Koda it's in menu: File/Import/Import AutoIt GUI

and it imports from AU3 script to KXF.

Edited November 2, 2007 by Zedna

[Lazycat]

1. There is a one way relationship from Koda to the AutoIt script. It would be nice to read changes from the script back into Koda, to update it. This kind of relates to opening a non-Koda .au3 file and converting it. Here is a situation. I create a button and give it a generic function for onclick, since I have yet to do the coding. While coding, I set the function name. I then have to open Koda and re-set the function to the new on I created, then update script. It would be nice if I could modify the code for Koda and just update the function call.

For converting au3 files you can use import. It's not perfect yet, but will grow up.

When you talking about dynamic updating form from text being editing - this very likely never be done. I'm not say it's impossible, but very close. This will require an insane amount of code and doubt this will be reliable enough ever. Even Delphi IDE not going so far. So no "back direction" in realtime.

2. Not a Koda issue but scite. When in scite, I select tools and koda. I modfiy the gui to my hearts content. But I have to exit koda to test it. Scite tools are locked out. I'm probably doing things a**backwards, but here is what I do. open the au3 in scite. in scite go to tools and koda.

Scite get code via console, but Koda is GUI application, not console. Not sure that exists any way to send buffer to Scite until Koda closed.

I recommend you use Update function instead. Think it should fully cover this issue. Follow instructions in help file to make things work. Then while changing form just press Ctrl+U from Koda and gui part in your script will be updated.

[Guest BillBeavis]

I may have spotted something. The help on my koda says 1.6.0.2. This is from a bundled scite install, does the latest scite/autoit have the latest koda?

[Guest BillBeavis]

How do you assign an onevent function to a menuitem created using the menu builder in koda? The object browser doesn't have an option.

[Zedna]

I may have spotted something. The help on my koda says 1.6.0.2. This is from a bundled scite install, does the latest scite/autoit have the latest koda?

Latest Scite4AutoIt3 doesn't contain latest Koda 1.7. It will be in the next Scite4AutoIt3 version.

You must download latest Koda 1.7 separatelly for now.

[Guest BillBeavis]

This may be a silly question, but couldn't you use Koda and AutoIt to create the next version of Koda. Instead of Delphi?

[JohnBailey]

How do you assign an onevent function to a menuitem created using the menu builder in koda? The object browser doesn't have an option.

Manual Method: You must click on the Menu1 Control. In the inspector click the "..." on the Items line. Select an item then in the inspector click the onclick line.

[martin]

This may be a silly question, but couldn't you use Koda and AutoIt to create the next version of Koda. Instead of Delphi?

It's not a silly question and it could all be done in Autoit I expect, and at least one person is trying to do just that. But a program like Koda can be developed very much more quickly and easily IMO, and have more features, by using a powerful development tool like Delphi. Lazycat might have other reasons.

[Lazycat]

This may be a silly question, but couldn't you use Koda and AutoIt to create the next version of Koda. Instead of Delphi?

Maybe not silly, but hasty Well, here at least two reasons why this have less chances to be done, then even bidirectional relations between code and form

We have a many languages, every of them are more or less suitable for programming certain tasks. C probably is most multi-purpose; Delphi is very good for making complex GUI apps and working with databases; Autoit - for automating, parsing/converting jobs, making simple GUI apps etc. Of course, it's possible to write GUI editor in Autoit. But this like situation when noone writing drivers in Delphi - not because it's impossible, but hard.

GUI Builder is great attempt. Once I'm myself trying to continue this project. But when lookfar first come with FormDesigner (name of project prior to Koda) and asked for volunteers, I decided this more promising, because project was in Delphi and show big potential.

Second but not least - it's just impossible directly port Koda to Au3. It may looks simple, but it still few thousands lines of our-written code along with few third-party components. This developed about three years, and only now it's become stable enough. Well, imagine we decide write Koda 2.0 in Autoit. Switching to another language lead to dropping almost all current code and remake program from scratch. Even taking in account that some parts will be easier to write in Autoit, writing GUI part with similar features will be a big pain. So, what you prefer - use current Koda written in Delphi, or wait another years?