GUI Designer: Koda 1.7.3.0

[Guest BillBeavis]

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.

Your last sentence is where I am stuck. I don't see an onclick line in the inspector. For TMenuItem objects I have AutoCheck, Caption, Checked, Default, Enabled, GroupIndex, Hint, Name, RadioItem, Visible. Is there a separate update for Menu Designer apart from Koda?

[JohnBailey]

Your last sentence is where I am stuck. I don't see an onclick line in the inspector. For TMenuItem objects I have AutoCheck, Caption, Checked, Default, Enabled, GroupIndex, Hint, Name, RadioItem, Visible. Is there a separate update for Menu Designer apart from Koda?

Do you have any menuitems?

[JohnBailey]

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?

Lazycat, I must say! Wonderful breakdown and explanation in my opinion, especially the language comparison!! I think this is a much need post in this thread and for me just to read a skilled and tenured programmer's breakdown on a project like this with a comparison!

Nicely down

[Guest BillBeavis]

Do you have any menuitems?

OK, where's the camera crew?

I read your reply and said to myself "of course", but went to test anyway. I verified that onclick was not listed and for s**ts and giggles decided to create a new menuitem. For the new item, onclick exists (as well as bitmap), but not for pre-existing ones. Also the object type is different. Old is TMenuItem, and new is TAMenuItem. I would swear that I created this test GUI under the latest Koda, but my only reasoning is that I created this GUI in 1.6 prior to updating to 1.7.

/All you kids get off my lawn!

[Guest BillBeavis]

@Lazycat

I agree that changing gears to a different language would be a complete restart. My comment was more hypothetical. Kind of a comment to the advance state of AutoIt/Koda, where it could create it's own tools. Kind of paradoxical, like timetravelers being their own grandfathers.

[Guest BillBeavis]

FYI for anyone interested

change the line similar to this

command.12.$(file.patterns.au3)="$(SciteDefaultHome)\Koda\FD.exe" /Scite

to

command.12.$(file.patterns.au3)="$(SciteDefaultHome)\Koda\FD.exe" "$(FilePath)" /Scite

in C:\Program Files\AutoIt3\SciTE\au3.properties

That way alt-m or tools>koda in scite will open the file you have active.

/let me guess, this was fixed in 1.7 already?

[Lazycat]

For the new item, onclick exists (as well as bitmap), but not for pre-existing ones. Also the object type is different. Old is TMenuItem, and new is TAMenuItem.

Yeah, this was the biggest mistake in 1.6 release where I forget to add onclick for menu item Probably this issue badly documented or undocumented at all, I'll look. For instance you can just search and replace TMenuItem to TAMenuItem in kxf file.

I agree that changing gears to a different language would be a complete restart. My comment was more hypothetical. Kind of a comment to the advance state of AutoIt/Koda, where it could create it's own tools. Kind of paradoxical, like timetravelers being their own grandfathers.

Ok This is exactly what with Delphi IDE - it written in Delphi itself. Surely, it possible with Koda too, but afraid will require too big effort.

[Ghost21]

Hey LazyCat,

First of all KODA kicks some ass I love it ...

Questions:

- I switched from 16.0.0 to 17.0.1 and I noticed when I generated code it put $AInput1 for example where the old version just had $Input1 is there a way to get rid of that " A " ??

- Next when the code is generated in it line wraps but doesn't add in an _ eg:

Doesn't Work

$AInput27 = GUICtrlCreateInput("pbs-wch", 408, 193, 225, 22, BitOR($ES_CENTER,

$ES_AUTOHSCROLL))

Does Work

$AInput27 = GUICtrlCreateInput("pbs-wch", 408, 193, 225, 22, BitOR($ES_CENTER, $ES_AUTOHSCROLL))

I think it can be done that way too ???

$AInput27 = GUICtrlCreateInput("pbs-wch", 408, 193, 225, 22, BitOR($ES_CENTER, _

$ES_AUTOHSCROLL))

Is that a bug I don't know just wondering if it can be changed or I'm just missing an option..

Thanks

Ghost

[Lazycat]

This is due changes in method of creating default names in new version. Here is a converter, that will help you with those names:

http://www.autoitscript.com/forum/index.php?showtopic=53122

About second - Koda is not add linewraps anywhere. This is probably your editor issue.

[BrettF]

This is due changes in method of creating default names in new version. Here is a converter, that will help you with those names:

http://www.autoitscript.com/forum/index.php?showtopic=53122

About second - Koda is not add linewraps anywhere. This is probably your editor issue.

It does it for me in Scite too?

[Lazycat]

Don't know. I can prove, that Koda itself not break lines. If you have an example form where you encounter this - please post it.

Yeah, found a problem. Though generating of code ok, this can break lines in output window. Thanks, will try to fix.

Edited November 16, 2007 by Lazycat

[Ghost21]

Don't know. I can prove, that Koda itself not break lines. If you have an example form where you encounter this - please post it.

Yeah, found a problem. Though generating of code ok, this can break lines in output window. Thanks, will try to fix.

Great Thank you very much..

[Valik]

I just had a look at the latest Koda. The first thing that strikes me... it's hard to use for a reason obviously not considered:

Being able to actually read the UI seems important.

Remember, never use fancy foreground colors unless you're going to control the background, too. I complain about that all the time to people on the forum who uses greens and reds which clash harshly with my dark themes. The same applies for UI design. You should always try to respect Windows themes as much as possible. If you *must* use font colors, control the background as well, or provide "dark theme" alternatives.

[Lazycat]

Customizing colors is a feature, that already in todo a long time, but since noone complain yet, it continually delayed.

Object inspector contain a bunch of properties, and different colors are make distinguish easier with "quick look". But agree, that at least non system dependent colors should be customizable.

Edited November 18, 2007 by Lazycat

[Lazycat]

We some time think about independent updating GUI controls code, what allow to preserve auxiliary code in the generated GUI section, but faced with serious problem here.

It's obvious, for that we should to know which control in form is correspond to control in script. Well, this is easy when we have control name (which is unique) - this is way like Delphi IDE work.

But when we clear control name (regular practice for labels, and not too rare in event mode), control in script loose originality and Koda can't distinguish between, say, two labels. If we force to always use variables, code will be too garbaged.

So, I'm placed this question here, maybe someone bring some fresh idea how to solve this problem. Instead we likely will drop idea of independent generation at all.

I'm not sure that generating every control independently is absolutely needed. Of course, this can be a bit more convenient, but finally, all initialization of controls, that require additional scripting, can easily be done just below the end of GUI section. So now this matter of possibility and effort for it's realization.

Ideas? Opinions?

[MrCreatoR]

There is a small bug(?) in the Koda...

When we open a template "About Box", and press the “Generate Code” button, we get the source dialog, but there is missing picture (GUICtrlCreatePic("", ...)), i know that the picture is built into the template, but i think it should be available as real path to the image (keep it in the templates dir?).

And also, there is GUISetIcon("D:\00?.ico") in moust of the templates, is this should be there?

P.S

Thanks for this tool, i generaly type the whole gui without using any tool (this is how i used to do it ), but sometimes this can be a very handy tool!

Edited November 26, 2007 by MsCreatoR

[Zedna]

...

I'm not sure that generating every control independently is absolutely needed. Of course, this can be a bit more convenient, but finally, all initialization of controls, that require additional scripting, can easily be done just below the end of GUI section. So now this matter of possibility and effort for it's realization.

Ideas? Opinions?

So make it optional.

In Options add some new checkbox for that behaviour

and users will choose their choice.

[Lazycat]

When we open a template "About Box", and press the “Generate Code” button, we get the source dialog, but there is missing picture (GUICtrlCreatePic("", ...)), i know that the picture is built into the template, but i think it should be available as real path to the image (keep it in the templates dir?).

And also, there is GUISetIcon("D:\00?.ico") in moust of the templates, is this should be there?

Correct

Another thing was planned formerly - something like "resource manager", that can handle this situation, but it's still in plans...

So make it optional.

In Options add some new checkbox for that behaviour

and users will choose their choice.

Unfortunately, this is not case where option is a straight way. This mean feature will be only half-functioning.

I think, it's not too frequent need to place code between generated controls - I can only imagine case, for example, when you need dynamically create array of controls. Maybe this can be done in other way.

Edited November 28, 2007 by Lazycat

[Enforcer]

hi LazyCat, i think in new version Koda needs some funktions like (jus ideas):

> When you double click on control it opens you event editor like in delphi

> In background i think always need opened editor so you can view and edit what you creating

> some new funktions like: ToolBar with icons, statusbar, splitter, richedit something like that will be more interesting

> will be interesting to see some of speed/macross buttons to quick paste some of scripts in projects

sooo i think thats all... for first time...

- found a bug or kind of that - when creating a window and control on it, with the same color, control color not changing...

- if you create textlabel, then resize it, then save and open it again, his size will be dafault, thats not nice ...

p.s: need normal status bar (in Koda) i'm tired to create it from text label... :\

вобщем эт Я Битник Инглиш немного подзабыл но думаю идея ясна, а вообще рулёзно получилось, что русский чел замутил Оболочку к Американскому языку программирования вааааще улёт ))

Edited November 28, 2007 by Enforcer

[Zedna]

I'm missing StatusBar support in Koda very much too.

EDIT: and ToolBar too

Edited November 28, 2007 by Zedna