GUI Designer: Koda 1.7.3.0

[martin]

This all weird, especially AX editor reference. Can you try this version

http://www.autoitscript.com/fileman/users/Lazycat/koda_test_compr.zip

in separate folder, look for error message, and if this different from one you posted before, post it?

Also, I'm uploaded uncompressed version to be sure this problem is not UPX related.

http://www.autoitscript.com/fileman/users/Lazycat/koda_test_nocompr.zip

Now this behaviour is expected:

because Koda try to parse and load file from path given in the input. In this case you can for example type "shell32.dll" and got list of icons, path will be remain just "shell32.dll".

If this made as you suggest, you can have one picture loaded, but address totally different in input...

From other side, I'm understand your desire to using @ScriptDir here... Not sure how to do this better. Add some checkbox "fix picture", after checking you can change path as you want while picture will remain untouched? But this option need to be saved...

Or better disable inputbox until picture will be loaded? This drop ability using "shell32.dll" syntax, but if this will be fully independent, you still can use it. Anyway, I'm don't like situation, when user can save "picture path" (formally correct or not) while picture not loaded.

Any another good ideas?

I get errors with both the compressed and non-compressed version. The error shown is this

(The word under the cursor is EnsureSlash)

Maybe instead of Custom path you could have a place for 'Path to file to be used in script', but after the picture is loaded. A new field in the properties seems like the best place; 'Application Path to File' maybe. The path used for Koda must be remembered but just for Koda. If this special path was just used literally in the code generation then someone could use a variable name or relative path or whatever.

[Lazycat]

I get errors with both the compressed and non-compressed version. The error shown is this

(The word under the cursor is EnsureSlash)

Well, now I sure you used wrong debug file Think I'm better will include it in each beta, this only 300 kb additional size, but as you see this file useless when versions don't match.

Maybe instead of Custom path you could have a place for 'Path to file to be used in script', but after the picture is loaded. A new field in the properties seems like the best place; 'Application Path to File' maybe. The path used for Koda must be remembered but just for Koda. If this special path was just used literally in the code generation then someone could use a variable name or relative path or whatever.

In fact, when Koda loaded picture, it's path need only for code generation. So this property can be reused.

So I try this idea: custom name inputbox disabled until picture loaded. When it loaded, it's path placed in input and it enabled. You will change it as you like and save.

When you load new picture steps above repeat again.

[martin]

Well, now I sure you used wrong debug file Think I'm better will include it in each beta, this only 300 kb additional size, but as you see this file useless when versions don't match.

I thought the debug file you refer to was the FD.MAP file which you included in the compressed and uncompressed versions I tried. I unzipped the downloads into different folders, and then I ran Koda from those folders at different times, so I thought the FD.MAP file would be correct for the version of FD I was running. I made a screen shot of the error message for the koda_test_compressed one.

What should I have done?

In fact, when Koda loaded picture, it's path need only for code generation. So this property can be reused.

So I try this idea: custom name inputbox disabled until picture loaded. When it loaded, it's path placed in input and it enabled. You will change it as you like and save.

When you load new picture steps above repeat again.

I'm not sure about this idea if I understand it right. There needs to be a path which is saved with the GUI design, and a path2 which is saved with the GUI design and used for the Autoit code. If the path used to load the image for the design is not saved then the next time you run Koda the image will not be there.

I think the idea of having a new image property called something like 'Script Source Path' would be best. This could be set to be the same as the path used to load the file when the image is loaded.

[Lazycat]

I thought the debug file you refer to was the FD.MAP file which you included in the compressed and uncompressed versions I tried. I unzipped the downloads into different folders, and then I ran Koda from those folders at different times, so I thought the FD.MAP file would be correct for the version of FD I was running. I made a screen shot of the error message for the koda_test_compressed one.

What should I have done?

Now all ok, your second screenshot show a correct bug target. First one show impossible target, so most likely was taken with wrong fd.map file (maybe from previous beta).

I'm not sure about this idea if I understand it right. There needs to be a path which is saved with the GUI design, and a path2 which is saved with the GUI design and used for the Autoit code. If the path used to load the image for the design is not saved then the next time you run Koda the image will not be there.

I think the idea of having a new image property called something like 'Script Source Path' would be best. This could be set to be the same as the path used to load the file when the image is loaded.

When picture loaded, it's saved in the form, so it's not need path anymore...

I'm planned to leave path editing place when it is instead property (it's too small imo for edting complex strings like this path), but maybe.

[AMD]

First off...I can not say how much of a blessing this makes working or creating GUI's with autoit...Hands down.

Now with that aside I would like to bring to light something that drives me crazy, the issue is with the object treeview window, it loves to jump to the bottom of the list any time you are doing a couple of things ( can't recall at this very minute). And the levels are always fully expanded, fold them up except the section you are working on, adding a ctrl, editing a prop of a ctrl, ect...and they all go bach to being fully expanded.

I wouldn't see it being a huge prob if you only work on smaller gui's but my last couple have been large and trying to scroll from one end of the list to the other constantly, gets old real quick.

Once again, thanks for the hard work you have put into this already!!

[Lazycat]

First off...I can not say how much of a blessing this makes working or creating GUI's with autoit...Hands down.

Now with that aside I would like to bring to light something that drives me crazy, the issue is with the object treeview window, it loves to jump to the bottom of the list any time you are doing a couple of things ( can't recall at this very minute). And the levels are always fully expanded, fold them up except the section you are working on, adding a ctrl, editing a prop of a ctrl, ect...and they all go bach to being fully expanded.

I wouldn't see it being a huge prob if you only work on smaller gui's but my last couple have been large and trying to scroll from one end of the list to the other constantly, gets old real quick.

Once again, thanks for the hard work you have put into this already!!

Not sure what you mean as "it loves to jump to the bottom". Koda should not jump suddenly, it just always keep selected item in the visible area of treeview. When you insert new control, it appear at bottom and become selected, so Koda jump to bottom correspondely. Or what couple things you mean?

About treeview expanded state - yes, now it is. Tracking folded/expanded state was too complicated thing. Maybe I'll return to it once and try to change.

[martin]

Version 1.6.1.9(Beta)

How do I update my scripts when I change a design?

I've set the script file and kxf file in Project Manager.

If I click on Update and Save Project the script isn't updated.

[Lazycat]

Version 1.6.1.9(Beta)

How do I update my scripts when I change a design?

Probably I should disable those items, because project manager is not workable yet (use old update method). I'm leave it in hope someone can suggest some good idea, how better to manage scripts/forms together.

[martin]

Probably I should disable those items, because project manager is not workable yet (use old update method). I'm leave it in hope someone can suggest some good idea, how better to manage scripts/forms together.

OK, 'Ctrl U' still works but there is no menu option to update any more.

The project method you are developing looks good to me. It means, I assume, that you can enter the scripts used and they do not need to be in the same folder as the kxf file. You could have a standard form for something which is used in more than one project.

Maybe you need to lay the information out differently, because when there is more than one design and more than one script how do you be sure which design belongs to which script? Perhaps they could be arranged in 2 columns of a list view; column 1 is design, column2 is associated script. Then you might say the form will have to be too wide, so maybe you just have the design and path shown, and right click for it's properties to set the associated script.

What is the 'Main' form? The way the forms are displayed or used is determined only by the scripts, or are you thinking ahead a bit here?

I think a good option would be to say that whenever a design is saved then the script is updated as well.

Small points about the Project Manager window:

The 'Close' button does nothing. Close doesn't make me think that changes will be saved. Could we have 'Save and Close' and 'Cancel'?

The 'Remove script ' button doesn't prompt for confirmation, and it also removes the form.

There is no 'Add Form' button.

[Lazycat]

Well, this kind of responce I wanted I'm paused atm with project manger, because this serious addition, and I want design this as good as possible.

It means, I assume, that you can enter the scripts used and they do not need to be in the same folder as the kxf file.

Correct, this is one of goals of introducing projects.

You could have a standard form for something which is used in more than one project.

Had not such thought, but this is good point.

Maybe you need to lay the information out differently, because when there is more than one design and more than one script how do you be sure which design belongs to which script? Perhaps they could be arranged in 2 columns of a list view; column 1 is design, column2 is associated script. Then you might say the form will have to be too wide, so maybe you just have the design and path shown, and right click for it's properties to set the associated script.

In this manager I think go "from script". This mean, because script can have multiple forms, this should be "first level". This probably can be changed.

What is the 'Main' form? The way the forms are displayed or used is determined only by the scripts, or are you thinking ahead a bit here?

When you preview just one form - all ok. But when you want preview work of whole project, you have to know, which script is "main" and should be executed.

I think a good option would be to say that whenever a design is saved then the script is updated as well.

Running project should update all scripts and save all forms. Here also can be some optional variants.

The 'Close' button does nothing. Close doesn't make me think that changes will be saved. Could we have 'Save and Close' and 'Cancel'?

This unfinished... But this make sense. I think avoid additional menu items for saving project, it should be done whenever you click "ok" (or "save") in project manager.

The 'Remove script ' button doesn't prompt for confirmation, and it also removes the form.

There is no 'Add Form' button.

This is early stage...

[martin]

When you preview just one form - all ok. But when you want preview work of whole project, you have to know, which script is "main" and should be executed.

Yes, the main script is important, and each script can have more than one form. Maybe a treeview would do the job

[pixels75]

KODA is a very nice add-on for AutoIt but I still dont understand the way he associate au3 and kxf.

You're supposed to pick the line from SciTE, like

#Region ### START Koda GUI section ### Form=U:\Dev\AutoIt3\TestForm\FormMain.kxf

and open the kxf on KODA with a Ctrl-m based on the path on Form= ?

Why is there an option in KODA for opening the last form at KODA start-up ?

The cursor on the right line on SciTE, Ctrl-m, and voila ! That's enough for me.

And that's not really working all the time for the moment... Or maybe I've missed something

[martin]

KODA is a very nice add-on for AutoIt but I still dont understand the way he associate au3 and kxf.

You're supposed to pick the line from SciTE, like

#Region ### START Koda GUI section ### Form=U:\Dev\AutoIt3\TestForm\FormMain.kxf

and open the kxf on KODA with a Ctrl-m based on the path on Form= ?

Why is there an option in KODA for opening the last form at KODA start-up ?

The cursor on the right line on SciTE, Ctrl-m, and voila ! That's enough for me.

And that's not really working all the time for the moment... Or maybe I've missed something

Some of this was answered in reply to your previous post before you duplicated it here.

[pixels75]

Some of this was answered in reply to your previous post before you duplicated it here.

Oops, my mistake...

BTW, with KODA 1.6.1.9 (beta), I'm stuck, when I try to save a form, to an error message "Cannot open file "C:\...\dump".

Any idea ? Thanks...

[AMD]

Yes, the main script is important, and each script can have more than one form. Maybe a treeview would do the job

I like this idea..alot

[martin]

Oops, my mistake...

BTW, with KODA 1.6.1.9 (beta), I'm stuck, when I try to save a form, to an error message "Cannot open file "C:\...\dump".

Any idea ? Thanks...

I don't have this problem in 1.6.1.9(beta). I assume you are saving using Ctrl S.

Maybe you need to use an earlier version of Koda untill LazyCat can help.

Edited June 20, 2007 by martin

[pixels75]

I don't have this problem in 1.6.1.9(beta). I assume you are saving using Ctrl U.

Maybe you need to use an earlier version of Koda untill LazyCat can help.

Even with "Save As" in menu... Back with the previous version for the moment...

[Lazycat]

Oops, my mistake...

BTW, with KODA 1.6.1.9 (beta), I'm stuck, when I try to save a form, to an error message "Cannot open file "C:\...\dump".

Any idea ? Thanks...

You downloaded version right after it introduced. But there was a forgotten debug code. I'm reuploaded fixed version after report about this. So just download last version again.

Yes, the main script is important, and each script can have more than one form. Maybe a treeview would do the job

I'm like this layout too. Will look, if this can be done this way.

[Zedna]

Here is updated Czech language file (from version 1.6.1.5 to 1.6.1.9).

During translation I noticed some translation related erros:

1) Project Manager dialog - is not in XML (can't be translated)

2) Save all - <actSaveAll> is in XML but is not translated at runtime

3) Manage project files... - <actProjectManager> is in XML but is not translated at runtime

4) after New Project and select existing KXP file appears messagebox with text: Prompt should be here --> should be text: Do you wan't to overwrite existing project file? --> this text should be also in XML for translation

5) after New Project appears messagebox with text: Creating new project will close currently opened project and all it's forms. Continue? --> but there is only OK button (and not Yes/No buttons) --> this text should be also in XML for translation

6) <actSaveUpdate property="Caption">&amp;Update &amp;&amp; Save Project</actSaveUpdate> --> in menu is one space added at start of menu string

7) <Label1 property="Caption">Undo levels (0 - disable)</Label1> - label should have bigger width for long Czech translation: Počet úrovní pro příkaz Zpět (0 - žádná)

and some no translation related:

8) Project manager dialog is resizable - but controls are not changing it's position/size

9) history.txt --> Beta 1.6.1.8 (2007-06-09) should be Beta 1.6.1.9 (2007-06-09)

EDIT:

10) GUICtrlSetResizing() code is not generated for ListView and Group controls --> this is bad bug!

11) GUICtrlSetResizing() code is not generated for any controls placed inside Group control

Edited June 22, 2007 by Zedna

[Lazycat]

Here is updated Czech language file (from version 1.6.1.5 to 1.6.1.9).

During translation I noticed some translation related erros:

1) Project Manager dialog - is not in XML (can't be translated)

2) Save all - <actSaveAll> is in XML but is not translated at runtime

3) Manage project files... - <actProjectManager> is in XML but is not translated at runtime

4) after New Project and select existing KXP file appears messagebox with text: Prompt should be here --> should be text: Do you wan't to overwrite existing project file? --> this text should be also in XML for translation

5) after New Project appears messagebox with text: Creating new project will close currently opened project and all it's forms. Continue? --> but there is only OK button (and not Yes/No buttons) --> this text should be also in XML for translation

6) <actSaveUpdate property="Caption">&Update && Save Project</actSaveUpdate> --> in menu is one space added at start of menu string

7) <Label1 property="Caption">Undo levels (0 - disable)</Label1> - label should have bigger width for long Czech translation: Počet úrovní pro příkaz Zpět (0 - žádná)

and some no translation related:

8) Project manager dialog is resizable - but controls are not changing it's position/size

9) history.txt --> Beta 1.6.1.8 (2007-06-09) should be Beta 1.6.1.9 (2007-06-09)

EDIT:

10) GUICtrlSetResizing() code is not generated for ListView and Group controls --> this is bad bug!

11) GUICtrlSetResizing() code is not generated for any controls placed inside Group control

Thanks for findings, I'll apply them when back from vacation (sunday I think). Please don't worry much about project manager, it quite unfinished now and lots of things are subject of change.