IDE for GUI: Any coders?

[livewire]

New update (GUIBuilder_8):

- updated grid refreshing (check it out in Settings->SetGridTicks)

- GUIBuilder output (removed Exit and GUICreate style options)

- also other misc stuff.

Extract this to your Scite GUIBuilder directory (ex. "C:\Program Files\AutoIt3\Scite\GUIBuilder")

**requires Beta**

-Livewire

Edited August 20, 2005 by livewire

[livewire]

New update (GUIBuilder_9):

- updated menu (File,Open,Edit,Save,etc...)

- added right-click functionality (copy,paste,delete,properties)

- added extended properties (Font, Color, Enabled, etc) ***currently for "Button" control only***...the rest coming soon

- other misc updates

I will be adding the rest of the extended properties during this week. Please let me know of any bugs or features you see missing...thanks.

Extract this to your Scite GUIBuilder directory (ex. "C:\Program Files\AutoIt3\Scite\GUIBuilder") if you like.

**requires Beta**

**edited Combo heights for Windows 2000 compatibility**

**added more properties to "Button" control (Alignment,Pic,etc)***

**fixed GUI_DISABLE stuff**

**some other minor stuff***

-Livewire

GUIBuilder_9.zip

Edited September 14, 2005 by livewire

[livewire]

I just fixed some minor stuff to the last revision...please download again. See previous post.

-Livewire

[therks]

Wow, this has come a long way since I last used it. Good job livewire.

I have a couple little bugs... not sure if they're old or new, but just stuff I found.

1) Not really a bug I guess but.. after exiting a properties window, the main GUI is forced to lose focus. For example, I created a control, edited the properties, and when I hit update, the window moved to the background and an Explorer window I had open came to the foreground. I know this is a "bug" with the enabling/disabling of GUI windows, but I found a good workaround is to call WinActivate after re-enabling a disabled window.

2) Not sure why, but create a button control. Now right-click > Copy. Now Paste. The control appears disabled. Normal?

3) Sometimes after I delete a control, the selection/resizing border still exists. If I happen to grab one of the corners AutoIt throws an error about exceeded array subscripts, and sometimes subscripts used with non-arrays.

Some of the errors:

Line 2550; Subscript with non-array. GUICtrlSetPos($overlay, $cp^ERROR

Line 3193; Subscript with non-array. Local $L = $p^ERROR

Line 3193; Error in expression. Local $L = $p^ERROR

(I actually got these previous two in one run, not sure how it threw two errors at me, usually the program just ends after one error, no?)

Line 3369; Subscript with non-array. GUICtrlSendMsg($currentCtrl, 27 + 0x0400, $h^ERROR

The only one I was able to consistently recreate was the error from line 3193. Just select a control, then grab one of the corners, and while holding the button down hit the Delete key and then try to move it. It's a user error I know, but just thought I'd mention it. The other two errors I just happened on while screwing around. Sorry I can't provide more info.

OS: WinXP Pro SP2

Thanks for continuing work on this really cool tool.

*Edit: Oh, one other little thing. If you right click a control that you haven't "selected" yet, the menu will appear, but function improperly. ie: If no control is selected, it does nothing, if a different control is selected, it will copy/delete that one. I could see that being a problem.

Edited September 8, 2005 by Saunders

[livewire]

Thanks for the input Saunders.

1) Not really a bug I guess but.. after exiting a properties window, the main GUI is forced to lose focus. For example, I created a control, edited the properties, and when I hit update, the window moved to the background and an Explorer window I had open came to the foreground. I know this is a "bug" with the enabling/disabling of GUI windows, but I found a good workaround is to call WinActivate after re-enabling a disabled window.

Implemented this fix...

2) Not sure why, but create a button control. Now right-click > Copy. Now Paste. The control appears disabled. Normal?

The issue of the button being disabled when copying should be fixed

Oh, one other little thing. If you right click a control that you haven't "selected" yet, the menu will appear, but function improperly. ie: If no control is selected, it does nothing, if a different control is selected, it will copy/delete that one. I could see that being a problem.

Implemented a fix...

Please re-download GUIBuilder_9 which now includes these fixes.

-Livewire

Edited September 8, 2005 by livewire

[steve8tch]

@livewire

Thanks for yor continued work.

[gcriaco]

GuiBuilder_8 worked fine inverting mouse buttons.

GuiBuilder_9:

Inverting mouse buttons, when you drag & drop objects on the form you'll see a "Paste" tooltip, with no possibilities to drop the object on the form.

BTW, many thanks for your meaningful improvement of GuiBuilder.

Edited September 14, 2005 by gcriaco

[livewire]

GuiBuilder_8 worked fine inverting mouse buttons.

GuiBuilder_9:

Inverting mouse buttons, when you drag & drop objects on the form you'll see a "Paste" tooltip, with no possibilities to drop the object on the form.

<{POST_SNAPBACK}>

Fixed...re-download GUIBuilder_9.

-Livewire

[Angel]

Hi! This is looking very good!

However, I still see that when I open the properties window and then I click on Update or Return the GuiBuilder window goes behind any window that was behind it.

Also, I have not been following this thread, but I cannot change any of the properties of the GUI elements, except for the name. Is that normal?

And is there a way to save the "Options"? GuiBuilder does not currently remember the grid size.

Finally, I'd be real cool to have some way to directly running the GUI. That is, GuiBuilder would generate the code into a temporary au3 file and then it would run it. That would allow you to test very easily your program.

All in all, thisis very very very cool!

Angel

[livewire]

I still see that when I open the properties window and then I click on Update or Return the GuiBuilder window goes behind any window that was behind it.

Sorry 'bout that...I only fixed this for the "Button" control previously...re-download GUIBuilder_9 with the fix.

Also, I have not been following this thread, but I cannot change any of the properties of the GUI elements, except for the name. Is that normal?

Only the "Button" control can change properties currently...I'm in the process of adding this functionality to the rest of the controls. They should be available in GUIBuilder_10. I just wanted to get feedback on the "Button" control first.

And is there a way to save the "Options"? GuiBuilder does not currently remember the grid size.

I will be implementing this sometime soon.

Finally, I'd be real cool to have some way to directly running the GUI. That is, GuiBuilder would generate the code into a temporary au3 file and then it would run it. That would allow you to test very easily your program.

That sounds like a good idea...I'll see what I can do.

-Livewire

Edited September 14, 2005 by livewire

[Angel]

Thanks! That problem is fixed now!

The properties window is VERY cool! I can't wait to get version 10. When can we expect it?!? :-)

And I have other suggestions:

- Could you add an "Apply" button to the properties window so that you could update the window without closing the properties window itself?

- Could it be possible to open the properties window by double clicking in the control for those controls that cannot be edited directly?

- Right Clicking on the background (main window) should allow you to set the main window properties (like whether it is modal or not, if the restore/maximize button is enabled, if it is resizable, etc), perhaps but opening another window from the contextal menu?

Finally, I wish that there was a way to link the "agd" files with the AU3 generated file and in particular with the CallBacks. Otherwise it is kind of hard to update a GUI once its au3 file has been modified (to add callbacks, etc). Perhaps GuiBuilder could create 2 files, one with the GUI declaration and another one for the callbacks (with the callbacks defined but empty). This file would be included automatically in the GUI definition au3 file. The user could just modify the _callbacks.au3 file.

When updating the file, GuiBuilder could check if the callbacks already existed. If they did, they would be left alone. If they didn't they could be added to the end of the _callbacks.au3 file.

What do you think? This seems complex but it could be worth it if properly implemented!

Cheers,

Angel

[livewire]

The properties window is VERY cool! I can't wait to get version 10. When can we expect it?!? :-)

Sometime soon...a matter of weeks...it was more complicated than I initially thought. A pretty stable version, GUIBuilder_10 should be available soon...depending upon how much free time I have.

- Could you add an "Apply" button to the properties window so that you could update the window without closing the properties window itself?

This is possible...I don't know if I will add this though...probably will.

- Could it be possible to open the properties window by double clicking in the control for those controls that cannot be edited directly?

Sure...I assume "those controls that cannot be edited directly" you are referring to menu,context menu, etc.

- Right Clicking on the background (main window) should allow you to set the main window properties (like whether it is modal or not, if the restore/maximize button is enabled, if it is resizable, etc), perhaps but opening another window from the contextal menu?

This sounds good. I will probably implement something like this.

Finally, I wish that there was a way to link the "agd" files with the AU3 generated file and in particular with the CallBacks. Otherwise it is kind of hard to update a GUI once its au3 file has been modified (to add callbacks, etc). Perhaps GuiBuilder could create 2 files, one with the GUI declaration and another one for the callbacks (with the callbacks defined but empty). This file would be included automatically in the GUI definition au3 file. The user could just modify the _callbacks.au3 file.

When updating the file, GuiBuilder could check if the callbacks already existed. If they did, they would be left alone. If they didn't they could be added to the end of the _callbacks.au3 file.

I don't really understand what you are talking about...maybe you can explain again.

[Angel]

Ok, let me answer your questions and make an extra suggestion:

Sure...I assume "those controls that cannot be edited directly" you are referring to menu,context menu, etc.

Yes, but also things like button, or graphic, etc, that you cannot just double click and edit (like the text controls).

Also, something that I believe would be very useful, specially combined with the "Apply" button that I requested (and that hopefully you will implement :-) ). What I'd love is to be able to keep the properties window open and have it update everytime that you click in one of the controls in the window.

This would be very useful because right now when I want to change stuff I need to keep right clicking on the controls, selecting properties and so on. I really think that this would be very very useful and make editing much easier.

By the way, I understand that the properties window thing is probably very complex so I am not surprised that it is taking you long! But the results so far are very impressive, so keep up the great work! :-)

I don't really understand what you are talking about...maybe you can explain again.

Ok, I was talking about this just today with a friend to whom I showed your problem. He also liked it a lot but saw the same issue that I see. So please let me elaborate:

Today, GuiBuilder generates 2 outputs: The agd file and the au3 file. You need to modify the au3 file to add the callbacks and to actually implement what you want the gui to do. Thus, once you have started modifying the au3 file it is hard to modify or update the GUI with GuiBuilder, because you can easilly update the agd file by loading it, modifying it and saving it again but you cannot do the same with the au3 file, which is the one that does the actual work.

In most "programming environments" that allow you to create a GUI you can create a first version of your gui, work on the behaviour of the program, then update the guI and so on but with GUI builder you are almost forced to do all you GUI work in the beginning as later it is difficult (or at least cumbersome) to update your au3 file.

So to solve this let's consider that all GUI programs have 2 parts: The GUI definition and the "Behaviour definition". GuiBuilder only is concerned with the GUI definition. The behaviour part is done by the user.

So GuiBuilder could perhaps do the following:

- GuiBuilder should let you set the name of the Callback function used for each control

- GuiBuilder should create 2 au3 files: the regular one that has the GUI definition and the main loop and the "behaviour" au3 file with the callbacks and other code (this one could be called the same but with "_behaviour" appended to its name).

- GuiBuilder creates and fully manages the "GUI definition file". It contains the code that currently GUI builder generates, but should also included the "Gui callback setting". This au3 file could be surrounded by a a special comment (lets say ";-- GuiBuilder GUI code -- DO NOT MODIFY" for instance) to show that this is managed by GuiBuilder. At the top of this function there should be an #include "yourfile_behaviour.au3".

- If "yourfile_behaviour.au3" does not exist GuiBuilder creates it for you but otherwise it does nothing with it.

So in this way, when the user modifies the GUI (by loading the agd file) and updates it, GuiBuilder can generate the GUI creation code again while not erasing the "behaviour" part of the script code. This way you can create a 1st version of the GUI, work on the functionnality (the behaviour) of the program, then perhaps update the GUI, and still have the program working with little effort on the part of the user.

Some people might argue that they like to have a single au3 file. In that case you could simply update the part within the "special GUI Builder comments" and let the user modify the rest. I would not mind either solution but I'd LOVE to see something like this implemented!

I hope I was clear. Please let me know if you have any questions!

Cheers,

Angel

[livewire]

@Angel

Thanks for the input. Those are very good recommendations and will all be considered.

[wfuehrer]

Hi!

Thanks for your great work.

It would be nice if gui builder would remenber the last opend directory. I organize my code on a second partition (not in My Documents) and i'm using many child windows in a project. I always have to switch to the work folder if i have to change something. At the moment i changed "@MyDocumentsDir" to "@ScriptDir" in the source and placed the gui builder in the project folder to have faster access to the forms.

[livewire]

It would be nice if gui builder would remenber the last opend directory. I organize my code on a second partition (not in My Documents) and i'm using many child windows in a project. I always have to switch to the work folder if i have to change something. At the moment i changed "@MyDocumentsDir" to "@ScriptDir" in the source and placed the gui builder in the project folder to have faster access to the forms.

Yea...that would be good. I will an .ini to the next release.

[TheSaint]

Greetings livewire!

I had not realised that someone else was working on CyberSlug's - GuiBuilder, when I posted some minor changes & updates on the 10th August 2005 - 12:25 AM.

Minor changes & updates

I had some brief talks with CyberSlug at the time, and your work was not mentioned (CyberSlug was probably not aware either, and may still be not, as I've not seen any comment by him (which I think is unusual for him).

I would like to commend you on your good work - keep it up! What you are doing is I'm sure very appreciated by the whole AutoIt community, and makes all our lives (programming ones at least) much easier - though I'm not sure how many are aware of your work, as your updated downloads are buried down deep in the section - maybe something should be done about that?

You may want to check out my minor changes & updates, which I have commented at the various sections I made changes to. In particular the last post you commented on to Angel, was just such an implementation I had added (ini file).

http://www.autoitscript.com/forum/index.ph...5&hl=guibuilder

Feel free to use anything I added (all rather simple really, compared to what you are doing), I'd really like to have those things in any further versions of GuiBuilder, as I've found it much better using them myself ... I'd hate to have to keep on adding them to every updated version I get, and I'm sure others would like them to!

TheSaint 0O-|-<

[livewire]

@TheSaint

Yea...I did run across your post yesterday and plan on implementing the .ini file and taking a look at whatever else you did.

I will probably start another GUIBuilder topic also, so everyone doesn't have to "dig" for the releases.

Thanks,

Livewire

[Angel]

@TheSaint

Yea...I did run across your post yesterday and plan on implementing the .ini file and taking a look at whatever else you did.

I will probably start another GUIBuilder topic also, so everyone doesn't have to "dig" for the releases.

Thanks,

Livewire

I think that GuiBuilder is so useful that it might merit having its own sticky thread in the AutoIt GUI forum, specially as it seems to be on the brink of becoming the "default" GUI creation tool for AutoIt. In fact, once it grows a little bit more it might be a good idea to include it (at least the au3 version) with the AutoIt3 installer...

Angel

[livewire]

I will start a new topic with my next release and get with jpm or whoever about getting it included in the installer. My version now requires beta, but I might create a non-beta version also.

-Livewire