297 replies to this topic

[billmez]

Great job on Koda, I use it all the time.

It woud be neat to be able to choose between event mode and GuiGetMsg() when creating a GUI.

The function to call for event mode could be included in the object inspector, and the template used could insert with the open/close functions rather than GuiGetMsg().

Just a thought :">

[Lazycat]

It woud be neat to be able to choose between event mode and GuiGetMsg() when creating a GUI.

This is one of things I try to get work now. But this require big change in code generator code, so stay tuned

[Gene]

This is one of things I try to get work now. But this require big change in code generator code, so stay tuned

Hi Lazycat,



While you're into the code generator it would be great if you could as an option the ability to fully populate the main loop for both modes with an instance for each control that can generate a message or an event.

If my intent is not clear, I'd be happy to discuss it at length or give an example.

Gene.

[Lazycat]

While you're into the code generator it would be great if you could as an option the ability to fully populate the main loop for both modes with an instance for each control that can generate a message or an event.

For current implementation I think to have "onclick" property in inspector, which will hold onEvent function name. This also can be used for generate message loop entries as flag, that control should have message loop entry. Only thing here: if you basically work in loop mode, you even don't need to see event function names and think about it. So most likely here will be two modes in Event Editor - event mode, when you can change name etc, and loop notification mode with only two variants - notify or not.
Full population in principle can be added, but this is really need?

[billmez]

For current implementation I think to have "onclick" property in inspector, which will hold onEvent function name. This also can be used for generate message loop entries as flag, that control should have message loop entry. Only thing here: if you basically work in loop mode, you even don't need to see event function names and think about it. So most likely here will be two modes in Event Editor - event mode, when you can change name etc, and loop notification mode with only two variants - notify or not.
Full population in principle can be added, but this is really need?

I agree with Gene that although it isn't life or death, it would be handy to have the loop fully populated for event mode, and also have functions that are created with the onclick property created as empty functions, along with the while 1/sleep loop, for event mode.

I think this would not only be a time saver, but also helpful to noobies in learning the GUI principles.

[Gene]

For current implementation I think to have "onclick" property in inspector, which will hold onEvent function name. This also can be used for generate message loop entries as flag, that control should have message loop entry. Only thing here: if you basically work in loop mode, you even don't need to see event function names and think about it. So most likely here will be two modes in Event Editor - event mode, when you can change name etc, and loop notification mode with only two variants - notify or not.

I think yes for three reasons...

Full population in principle can be added, but this is really need?

• While it would add a little complication for you, it would reduce work for everyone who uses Koda, at least for the first code generation of a new window.
• It would help newbies developing GUIs, their first effort would be more successful, nothing encourages effort like a little success. This would also hep them make sure they develop code for each control.
• You would be modeling good code practice for all to see.

I don't remember if I mentioned it before or not, but the request above include tabs among the controls.




While I was writing the above, another option occurred to me. In the last several months someone (I don't remember who at the moment) wrote a concept white paper and provided examples for a variable and child window naming scheme to reduce/eliminate confusion while developing or updating multi-window applications. It isn't a huge step from where you are or have talked about being with Koda to implement that or a similar scheme. Especially since you are reworking code generation anyway.



Gene

I'm going to try to find those posts...

[Lazycat]

I agree with Gene that although it isn't life or death, it would be handy to have the loop fully populated for event mode,

I think yes for three reasons...

Ok, I basically got the point. Btw, no big complication with full populate, this is again question of cluttering versus simplicity. Ok, option for full populate list will be added. But I doubt that it should be default.

I don't remember if I mentioned it before or not, but the request above include tabs among the controls.

Of course.

While I was writing the above, another option occurred to me. In the last several months someone (I don't remember who at the moment) wrote a concept white paper and provided examples for a variable and child window naming scheme to reduce/eliminate confusion while developing or updating multi-window applications. It isn't a huge step from where you are or have talked about being with Koda to implement that or a similar scheme. Especially since you are reworking code generation anyway.

Need to look. I remember this, but not exactly.

[Angel]

For current implementation I think to have "onclick" property in inspector, which will hold onEvent function name. This also can be used for generate message loop entries as flag, that control should have message loop entry. Only thing here: if you basically work in loop mode, you even don't need to see event function names and think about it. So most likely here will be two modes in Event Editor - event mode, when you can change name etc, and loop notification mode with only two variants - notify or not.
Full population in principle can be added, but this is really need?

Are you sure that "onclick" is the best name? For instance in EditBoxes it is not "onclick" but "onchange", right? So why not just use "OnEvent", as the corresponding AutoIt GUI function?

BTW, this is really great! I hope you implement this soon!

Also, I'd like to make a small request. Currently the only property that has "sub-properties". Right now it is always unfolded by default. Whenever I select a new GUI control it gets folder again. I'd be great if it could either always stay unfolded or at least remember the last state (folded/unfolded).

Thanks!

Angel

[Lazycat]

Are you sure that "onclick" is the best name? For instance in EditBoxes it is not "onclick" but "onchange", right? So why not just use "OnEvent", as the corresponding AutoIt GUI function?

These specs are not finished, so this can be changed. Moreover, each control can have own event, so no problem to make onchange for input/edit.
The reason of not have "generic" OnEvent name is fact, that in theory (in future) controls can have other events. Btw Form should have it now - onClose, onMinimize etc.

BTW, this is really great! I hope you implement this soon!

This is already done, just need some testing. More important is to decide naming convention for events, because changing that in future will break saved forms. So any thoughts are welcome.

Also, I'd like to make a small request. Currently the only property that has "sub-properties". Right now it is always unfolded by default. Whenever I select a new GUI control it gets folder again. I'd be great if it could either always stay unfolded or at least remember the last state (folded/unfolded).

Don't know if this possible, I have look.

[Angel]

These specs are not finished, so this can be changed. Moreover, each control can have own event, so no problem to make onchange for input/edit.
The reason of not have "generic" OnEvent name is fact, that in theory (in future) controls can have other events. Btw Form should have it now - onClose, onMinimize etc.
This is already done, just need some testing. More important is to decide naming convention for events, because changing that in future will break saved forms. So any thoughts are welcome.
Don't know if this possible, I have look.

I think that you understood me, but I re-read my post and I forgot to say the word "Font". That is, I meant that the only property that has sub-properties is Fonts and I'd like it to rememember its unfolded state (or, if it cannot be rememebered, be always unfolded by default).

As for the Events names, I think that now I understand the problem. So I'd suggest using the "default" event for each control type:

- onclick for Checkboxes and Buttons
- onchange for Editboxes and comboboxes (I know that for some comboboxes an event is fired when clicking on a different element, but that actually changes the current value).

Actually, checkboxes could either be onclick or onchange (both are the same). I don't know what would be better for other GUI controls...

Another alternative is to just use OnEvent. If in the future it is changed in AutoIt3 (that is, if new events are added) the new Koda could just read OnEvent and assign it to the "default" event (wich for buttons would be click, etc).

I hope what I mean is clear...

Thanks! I looking forward to the newer version! You should tell the Scite4AutoIt folks when you have it ready so that they update their installer as well!!!

Angel

[Angel]

I have one more suggestion for Koda (I don't know if someone else said this already). Please forgive me if it has already been discussed or if you think that this is out of the scope of your project.

The only realy problem that I have with Koda right now (specially now that you're going to add OnEvent support) is that it is hard to use Koda to update an existing GUI, even if it was generated with Koda. I'd be cool to be able to use Koda and Scite to directly update the GUI code in a script.

What I imagine is that perhaps Koda could add some lines around the code that it generates, and then you could have an "update button" that instead of creating a new file it would only update any code within the "Koda" lines. In this case the user could write the code outside the "Koda code" in his scripts and still use Koda to update that part of the code for you.

When using this "update mode" Koda would not need to generate the GUI message loop only, only the GUI creation code. And, when using Events, this wouldn't even be a problem, as the Msg loop is not used anymore...

What do you think?

Cheers!

Angel

[Stumpii]

I have one more suggestion for Koda (I don't know if someone else said this already). Please forgive me if it has already been discussed or if you think that this is out of the scope of your project.

The only realy problem that I have with Koda right now (specially now that you're going to add OnEvent support) is that it is hard to use Koda to update an existing GUI, even if it was generated with Koda. I'd be cool to be able to use Koda and Scite to directly update the GUI code in a script.

What I imagine is that perhaps Koda could add some lines around the code that it generates, and then you could have an "update button" that instead of creating a new file it would only update any code within the "Koda" lines. In this case the user could write the code outside the "Koda code" in his scripts and still use Koda to update that part of the code for you.

When using this "update mode" Koda would not need to generate the GUI message loop only, only the GUI creation code. And, when using Events, this wouldn't even be a problem, as the Msg loop is not used anymore...

What do you think?

Cheers!

Angel

Do a search for Kodawrapper.

[Angel]

Oh! And let me be even more ambitious (it is easy, as I am not the one doing the work! :"> ). Please bear with me and just tell me if you think that this is too far fetched (I realize that this could probably not be implemented soon, so it is just a suggestion for the future development of Koda).

What if you could somehow tell Koda that the value that you put in one of the properties (in the property editor) must be used "as is"? That is, what if I could put some "AutoIt3 code" embedded into one of the GUI properties?

Actually, today I can achieve this behaviour with the following trick:
- Set the property to: " & $MY_VALUE & " (note that I actually need the quotes in the property.
- The resulting code is:

GUICtrlCreateInput("" & $MY_VALUE & "", 136, 136, 441, 24)

Which actually achieves what I want, that is, to set the default string in the Editbox to the contents of the $MY_VALUE variable. Of course, I need to first make sure that I have defined $MY_VALUE in the code before the KODA generated code).

The problem with this trick is that it only works with Text Properties (which is probably not a big deal, as these are the ones in which this kind of trick would be more useful anyway). Also the extra "" & and & "" seem unnecessary.

So what I propose is that Koda could detect that I am using " in the beginning and the end of my property and remove it when it generates the code. This means that " would become some sort of "escape character" which tells Koda to embed whaterver I put in the property as if it was AutoIt3 code. The resulting generated code for my example would be:

GUICtrlCreateInput($MY_VALUE, 136, 136, 441, 24)


Of course I realize that this could give a few (perhaps a lot of) problems! In particular, what if you try to run the code from Koda?

Many of the problems could be fixed by:
- allowing the use of this "escape character" only for a small set of properties where it meaks sense (mainly the "Text" and "Caption" properties)
- using default values when Koda cannot evaluate a value
- adding the notion of "init code" to Koda: This would be some code that is exectuted at the beginning of the script and where you can initialize any variables that you use in the Koda properties. This could could be saved on the Form file so that when you open the form with Koda again this code is used to populate the Form that is presented in the Koda editor.

OK, that is is. As I say it can be done (with a bit of work) today. But it could be a nice future improvement, specially coupled with the Init code.

Thanks for reading this lenghy post!

Angel

[Lazycat]

- onclick for Checkboxes and Buttons
- onchange for Editboxes and comboboxes (I know that for some comboboxes an event is fired when clicking on a different element, but that actually changes the current value).

Actually, checkboxes could either be onclick or onchange (both are the same). I don't know what would be better for other GUI controls...

Another alternative is to just use OnEvent. If in the future it is changed in AutoIt3 (that is, if new events are added) the new Koda could just read OnEvent and assign it to the "default" event (wich for buttons would be click, etc).

Actually checkboxes are buttons, so onclick is more logical. Btw Delphi have onclick event for checkboxes, but not onchange.
Atm I incline to variant with different events. This is more flexible (and not sacrifice simplicity) but property name also give user the clue about on which cause control notify.

What I imagine is that perhaps Koda could add some lines around the code that it generates, and then you could have an "update button" that instead of creating a new file it would only update any code within the "Koda" lines. In this case the user could write the code outside the "Koda code" in his scripts and still use Koda to update that part of the code for you.

You right, something like was discussed. Kodawrapper do this.
Now Koda don't interact with output file, but this is not too hard to change. Probably this is can be done - at least as temporary solution. This can be done by adding field to form that will keep linked script, or maybe better, will automatically try to load script with same name as form.
Anyway, I think would be good to have some parser to import any gui code to Koda's kxf file. Sure, this should not be too hard with Au3 and Msxml. Any volunteers?

What if you could somehow tell Koda that the value that you put in one of the properties (in the property editor) must be used "as is"? That is, what if I could put some "AutoIt3 code" embedded into one of the GUI properties?
...
So what I propose is that Koda could detect that I am using " in the beginning and the end of my property and remove it when it generates the code.

Better detect it by $. I will think, maybe this can be added optionally like "use $VAR as is". For non-string variables - no way, sorry, this will require to rewrite almost 90% of custom controls code.

[Angel]

You right, something like was discussed. Kodawrapper do this.
Now Koda don't interact with output file, but this is not too hard to change. Probably this is can be done - at least as temporary solution. This can be done by adding field to form that will keep linked script, or maybe better, will automatically try to load script with same name as form.
Anyway, I think would be good to have some parser to import any gui code to Koda's kxf file. Sure, this should not be too hard with Au3 and Msxml. Any volunteers?

Wow, I wish I could help you but I really would not know where to start, never having used XML beofre, but this sure would make Koda the perfect GUI tool for AutoIt3! I will check Kodawrapper, but having this builtin into Koda would be perfect!
Can Kodawrapper be used with Scite? Sorry, I never heard of this before...

Better detect it by $. I will think, maybe this can be added optionally like "use $VAR as is". For non-string variables - no way, sorry, this will require to rewrite almost 90% of custom controls code.

I didn't want you to do this for non string variables. I realized that this would be very hard and that it did not make so much sense anyway :-)

Cheers,

Angel

P.S.- Again, thanks for writing this really cool tool!

[Stumpii]

Wow, I wish I could help you but I really would not know where to start, never having used XML beofre, but this sure would make Koda the perfect GUI tool for AutoIt3! I will check Kodawrapper, but having this builtin into Koda would be perfect!
Can Kodawrapper be used with Scite? Sorry, I never heard of this before...
I didn't want you to do this for non string variables. I realized that this would be very hard and that it did not make so much sense anyway :-)

Cheers,

Angel

P.S.- Again, thanks for writing this really cool tool!

Kodawrapper can be used with SciTe and UltraEdit.

[Lazycat]

The new beta version is out http://www.autoitscript.com/fileman/users/lookfar/koda_2006.04.11.zip. This have onEvent support in code generator (note, now only Button control have event - this until specs will be finished!), additional options for generation, experimental support for linked script (where you can replace only gui part, ready-for-use example in the Forms subfolder, use "Update" menu item to save form and update linked script).

[eltorro]

The new beta version is out http://www.autoitscript.com/fileman/users/lookfar/koda_2006.04.11.zip.

Great!

[ptrex]

Latest version does not run on my XP machine.

When starting ->Error Invalid arguments ?? -> craches

[Zedna]

Latest version does not run on my XP machine.

When starting ->Error Invalid arguments ?? -> craches

I have same problem and it was due to differrent name of KXF file and name of form inside KXF file.

<object type="TAForm" name="Form1">

It must be exact same also with case sensitivity!

And extension of file must be kxf (and not KXF or kxF, ...)

Edited by Zedna, 14 April 2006 - 02:37 PM.