Autoit3-gui

[jpm]

@jpm: the next problem is GUISetControlCurFont

Holger

for this version just always put a font name as "" if you want thed default

for other default set -1

Thanks for testing

[Lazycat]

I have tested Autoit3-gui and I very satisfied with it - for most my tasks this allow to avoid using Control* commands for handling form. The way for handling controls introduced in the Autoit3-gui is much more reliable then in AU3GUI(XP). The way of setting coordinates for controls a bit odd, but it is deal of habit.

No more bugs than kotschi have found at the moment. Only one thing is doubtful: imho "submit" is much more usable as default for controls. How you think? Maybe better to set default as "submit", or change GUISetControlAction function as GUISetControlCurFont works?

[jpm]

I have tested Autoit3-gui and I very satisfied with it - for most my tasks this allow to avoid using Control* commands for handling form. The way for handling controls introduced in the Autoit3-gui is much more reliable then in AU3GUI(XP). The way of setting coordinates for controls a bit odd, but it is deal of habit.

No more bugs than kotschi have found at the moment. Only one thing is doubtful: imho "submit" is much more usable as default for controls. How you think? Maybe better to set default as "submit", or change GUISetControlAction function as GUISetControlCurFont works?

I know Larry will like to have absolute coordonate more than relative.

I just want to have the size of a control reuse for positionning the next control

so x or y = -1 will add the corresponding size.

w or h = -1 the size will be compute by taking in account the control text size.

x=0 same row y=0 same line

Perhaps we can have special case of those values and have other absolute values.

Keep a GUISetControlPos to have one or the other starting point.

2. For submit I was thinking that the regular case is just to select something and have a button to close follow by the reading of the control state/value.

So no submit involve and button doing closing.

What do you think?

[alawoona]

I thought I like the relative positioning of controls but I am not sure now. For example, if I have written a gui and then decide to change the position of the first control, the positions of all subsequent controls change. This became apparent to me as I have almost finished a script that can be used to design and create another gui - for au3guixp. You can add controls, reposition them, resize them (based on some of Larry's code), delete controls, etc etc...it then writes the corresponding au3guixp code to a file that can be included in another script. Relative addressing would really screw this up.

I would like it as an option you can turn it on or off - absolute positioning or relative positioning.

Edited March 9, 2004 by alawoona

[Guest kotschi]

@jpm/alawoona: yeah, such a 'positioning'-mode-switch would be good but I don't know if it is so easy to program.

At the moment I work with the relative-postion-gui and have no problems.

Otherwise I use jpm's GUISetControlCurPos-function.

You know Au3GUIXp is a standalone-program so it's easier to program (@Larry: ok, it's not so easy I know )

And I think one problem is that the code of the whole Autoit3 with the GUI-functions will be bigger and bigger and I don't believe that is that so good for all of us cause to find an error in the code will be more difficult you know.

But that's only my opinion.

...

Hmmm...

For today it's enough... have to go sleep...

[jpm]

I thought I like the relative positioning of controls but I am not sure now. For example, if I have written a gui and then decide to change the position of the first control, the positions of all subsequent controls change. This became apparent to me as I have almost finished a script that can be used to design and create another gui -  for au3guixp. You can add controls, reposition them, resize them (based on some of Larry's code), delete controls, etc etc...it then writes the corresponding au3guixp code to a file that can be included in another script. Relative addressing would really screw this up.

I would like it as an option you can turn it on or off - absolute positioning or relative positioning.

I will have a try to change this default addressing.

I agree that changing one control position should not change every thing unless you want it.

Back to work for 100.3

Thanks for your valuable comments

[Jon]

Absolute controls are probably best. Then you can use various GUI designers (like the VC wizard) and then use the coordinates it generates to write your GUI.

[jpm]

Absolute controls are probably best.  Then you can use various GUI designers (like the VC wizard) and then use the coordinates it generates to write your GUI.

don't you think we can use value 0 and -1 for x,y,w,h for special case all other being absolute.

the only pixel not addresable will be 0,0

[Jon]

How about two modes which you can change between as you write your GUI?

GUICoordMode( 0 or 1 )

Then you can switch between the two as you write. So you can do a few controls in the (default) absolute mode and then if you want to switch to use coords relative the last control you added you switch modes?

The GUI would need to keep track of the coords of the last control added.

[jpm]

How about two modes which you can change between as you write your GUI?

GUICoordMode( 0 or 1 )

Then you can switch between the two as you write.  So you can do a few controls in the (default) absolute mode and then if you want to switch to use coords relative the last control you added you switch modes?

The GUI would need to keep track of the coords of the last control added.

I buy it

[alawoona]

How about an option switch 0 = absolute, 1 = relative in those commands that manipulate position, e.g.

GUISetControl ( type, "text", left, top [,width [,height [, 0 or 1 [,style [,exStyle]]]]

[alawoona]

Then you can use various GUI designers (like the VC wizard) and then use the coordinates it generates to write your GUI.

Are there any "WYSIWYG" GUI designers out there thet will also write the name of the control and values of X, Y, W, H etc to a text file. If so a script could be written to process that text file and create a GUI for AutoIt using AU3GUIXP or autoit-gui.

[jpm]

Are there any "WYSIWYG" GUI designers out there thet will also write the name of the control and values of X, Y, W, H etc to a text file. If so a script could be written to process that text file and create a GUI for AutoIt using AU3GUIXP or autoit-gui.

I am sure that Larry will come out with a AU3GUIScriptWriter

[jpm]

I have a fondamental question before declaring that the game is over.

what do you prefer ?

The actual definition which allows to make easy computation on parameter specially on position/sizing

for instance

GUICreate ("My GUI")
GUICreateEx ("",$input)

GUISetControl ("combo","",0,0)
GUISetControlData ("abc|def|ghi|jkl")

GUISetControl ("list", "", 0, 30)
GUISetControlData ("abc|def|ghi|jkl")

GUISetControl ("label", "eat spaghetti", 210, 0)

$c1=GUISetControl ("checkbox", "goober", 0, 250)
GUISetControlAction (2)

$c2=GUISetControl ("checkbox", "goober", 100, 250)

GUIExecute()

or something similar to Au3GUIXP which will have more "" and & if you want to compute the value

GUICreate ("My GUI", "background="& $input)
GUISetControl ("combo", "data='abc|def|ghi|jkl' ")
GUISetControl ("list", "data='abc|def|ghi|jkl', y=30)
GUISetControl ("label", "text='eat spaghetti', x=210, y=0")
$c1=GUISetControl ("checkbox", "text='goober', x=0, y=250, submit=1")
$c2=GUISetControl ("checkbox", "text='goober', x=100, y=250)

GUIExecute()

[alawoona]

I like the second approach better - but either works for me.

[jpm]

Already 2 votes same direction I am ready to go home but after dinner I check again and I start if the direction stay the same

[Valik]

I don't know why you would want the AU3GUIXP method whenever it's now possible to pass the information as a parameter. Since Au3Gui could only parse strings, I can understand the "data=blah;x=10;y=12" style, but since this is directly linked to the implementation of the GUI, I don't see why that's necessary or even desirable. The first thing I did to AU3GUIXP was wrap everything in functions so that I could do something like:

CreateGUI("Title", 10, 10, 100, 100)

Which created a GUI with the title "Title" at coordinates 10, 10 and was a 100x100 box. Naturally, the underlying implementation did all the concatenation to put the information in Au3GUIXP's format for me. I would think integrating the GUI stuff into AutoIt would be an opportunity to eliminate the need for the string-based approach and such wrapper's, but that's just my opinion. I've said before, if I don't like the way something works or its name, I'll just wrap it in functions of my own and be done with it.

[Valik]

I am all for breaking up into parameters until there are too many. I think the bulk can be parameters, then the options could be the last...

GUISetControl("button",$text,$x,$y,$w,$h,$style,$exstyle,$additional_info)

lar.

Oh, that reminds me. Another limitation of the wrapper library I wrote was that I had to seperate less used things into seperate functions because I couldn't specify optional parameters. Being built-in now, you can set it up to accept 20 arguments for all the information, or 2.

[jpm]

OK... I had some time away from the kids to think...

GUICreate([title [,x [,y [,w [,h [,style [,exstyle [,background [,icon [,help]]]]]]]]]])

I don't really like to have too many positional parameters.

Th AU3GUIXP is for me a nice work around before introduction of keyword in Function call.

so GUICreate($title, "background=n, help=file") is much nicer

I am planning to have the values evaluated no need to stop the string

as GUISetControl ("combo", "w=$width, data=$data ,submit=1")

I am sure Jon will comment on this syntax but when function call can have keywords just take out the " and that it.

So the functions can be

• GUICreate ( "title", "keywords, ...")
• GUISetControl ( "type", "keywords, ...")
• GUISetControlFont ( "font", "keywords, ...") <----- GUISetControlCurFont
• GUIExecute( [timeout] ) = GUIShow() for those not doing any interaction with the GUI
• GUIGetControlInfo(controlref)<------- GUIRead
• GUISetControlInfo(controlref [,state [,info] ] ) <------ GUIWrite
• GUIDelete()

[jpm]

no argument from me. I'm just so flippin' happy to get it implemented!!! 

I've leared a bit from studying the code also...

woohoo

As soon as you get the latest proposal implemented, I'm starting my GUIFormDesigner...

Lar.

I may stay with GUIRead, GUIWrite I am liking them at that can be coherent withe Create Delete Execute

To be franck I dont like too much function name with one letter change doing reverse.

I am starting the keywording stuff we will see.

PS does leared mean learned