GUI Changes Needed

[SlimShady]

... and you see lot's of "GUISetControlProperty" which causes confusion when reading the script.

[Holger]

@SlimShady: that is what I meant (ok, it's not confusing for me but for others)

But the problem is to manage a lot of properties for one control.

So I think there is no easy way to do it (without confusing)...

Edited September 3, 2004 by Holger

[SlimShady]

Currently we have 25 string functions.

So I don't mind seeing functions for everything.

I agree with Valik. I like his idea.

[jpm]

@SlimShady: that is what I meant (ok, it's not confusing for me but for others)

But the problem is to manage a lot of properties for one control.

So I think there is no easy way to do it (without confusing)...

<{POST_SNAPBACK}>

For me this problem can only be solve with parameter passed with keyword

$button = GUISetControl("button","...",15,10,25,25,$BS_ICON)

GUISetControlProperty(notify=1, tip="this is the default button", image="Shell32.dll:5:0")

;load image from file with ID 5 to button as small image (0=small,other=large)

You can have only one GuiSetControl with the parameters you select.

Today we don't have this type of construction.

Remember that the object oriented programming lead to a lot of setting property by property. :">

[Holger]

@jpm: sounds very interesting yeah...really

So you could take only the parameters you want and the sequence of them would not be necessary

It's remember me on the good 'old' Au3GUI from Larry which I first use as a scripting GUI...

In Au3GUIXP there are/were commands like:

EnvSet("OBJ3","type=button|text=&Submit|x=160|y=250|submit=1|close=1")

Yeah...back to the roots

Edited September 3, 2004 by Holger

[Valik]

No offense to Larry, at the time, his idea was good for the way he had to use to communicate, but that method sucked big time. It was way too confusing and ugly, especially if things were set by variables.

Besides, AutoIt isn't an object oriented language. In fact, it doesn't even have objects of any type at all except the generic variant.

Why does this have to be complicated or fancy? Why pass parameters as strings when they can they be arguments? Why should one function do everything?

Somebody argued that you'd have to remember a bunch of different functions using my method, but that's not true. You have to know the control you want to operate on, and that would be part of the function name. You also have to know what operation you want to do, which would also be part of the name. Jon has put a consistent naming scheme in place, so really, you only have to remember a handful of a functions (Which all correlate to a specific task, which you already know). Then the only thing that changes is the control to operate on.

[Holger]

So here are some new ideas from me:

These that we already have:

GUISetControlData(controlref,data[,default])

GUISetControlFont(controref,size[,weight[,fontname[,attribute]]])

GUISetControlNotify([controlref[,action]])

and the new:

GUISetControlBitmap(controlref,filename)

GUISetControlBkColor(controlref,backgroundcolor)

GUISetControlColor(controlref,textcolor)

maybe for that only:

GUISetControlColor(controlref,textcolor[,backgroundcolor])

GUISetControlIcon(controlref,filename[,iconid[,mode]]) -> mode -> 0=nonselected state, 1=selected state, 2=all states (default)

GUISetControlSmallIcon(controlref,filename[,iconid[,mode]]) -> mode -> 0=nonselected state, 1=selected state, 2=all states (default)

-> for buttons/menus/items(treeview,listview,toolbars,etc.later in the future)

GUISetControlLimit(controlref,max[,min])

GUISetControlResizing(controlref,resizing)

GUISetControlState(controlref,state)

GUISetControlText(controlref,text[,mode]) -> mode -> 0=erase previous (default),1=add to current control text (maybe for input, edit, buttontext,etc.)

GUISetControlTip(controlref,tiptext)

Ok, not all functions will be work with all controls but that is logical you know.

Maybe another one could be good - I don't have a clearly intention to it now - should be for mouseclicking (left, leftdouble, right, rightdouble) on a control you want, i.e.:

GUISetControlClick(controlref,clickmode)

So default will be 0 = left.

And when you set it to 1 then when you i.e. doubleclick on a listboxentry then the GUIMsg() will return the controlid too

But at the moment I don't know how to do it easy...it's to late - have to go sleep

Edited September 4, 2004 by Holger

[Valik]

poop brain

<{POST_SNAPBACK}>

I know you are but what am I?

Holger, those look pretty good (Although Larry is right about the naming convention). I could live with something like that. There is a logical distinction between what each function does.

Also, just an idea... Maybe there could be an advanced mode which expands GuiMsg() to return an array where $array[0] = Message, $array[1...n] = parameter(s) (Similar to WPARAM or LPARAM from the Windows API). That would allow for more Windows-like message handling. But that's just a thought (This thought was prompted by Holger mentioning the GuiSetControlClick(). This would be one way of being able to having a high-level event caught, but still offering low-level information for those who need such stuff).

[Jon]

Those look OK to me, Holger. With the naming convention changes. Maybe GuiControlAdd or GuiControlCreate instead of GUISetControl too.

A couple of other ideas would be handling multiple GUIs. I was pondering this and wondering if it was worth it and if it was easily without messing up the syntax of everything.

We could have it so that all Control IDs come from the same scheme so that even though there are multiple GUIs if you receive a message from a control ID you can handle it OK. So all the functions that work with control IDs should be OK as-is. All the rest of the functions like GuiShow would either have to have an additional parameter (for the gui number) or implement a GuiSwitch() function that just changes the currentgui that those commands work with. I'd have to rewrite the message handlers so that multiple guis are handled but I think it's doable. Maybe not until we've implemented the changes in this thread though - just something to bear in mind when making changes.

I don't want to go any more complicated that what is already in development (along with Holgers menu, extra controls). You could burn exe size forever in this area!

[Holger]

@Jon: ok I will convert/split off my GUIControlSetProperty-function to these like: GUIControlSetIcon, GUIControlSetLimit and so on and will send it JP, cause he is more in the whole GUI stuff

With the multi-gui I had the same idea last week, I tried something with a function like GUICreateChild and later with an array to save the normal window- and the parent-window-handle...

So if I clicked a control the the array would search trough and if the control window handle is the same like the normal window handle I had the parent window (gui) handle...

But I gave up the thing to extend the treeview-control and menu things with icons...

What I forget: how do you want the GUI-window-handle to implement int the control-commands?

with something like: GUIControlSet(wndhandle,type,text,....)

Ok, for the other commands I think it's not really needed ( I mean not GUIShow and GUIHide and maybe GUIRead- and Write) - GUIControlSetState and so on...

But only if you have an idea now how it could be...

So long...

Regards Holger

Edited September 6, 2004 by Holger

[jpm]

@Jon: ok I will convert/split off my GUIControlSetProperty-function to these like: GUIControlSetIcon, GUIControlSetLimit and so on and will send it JP, cause he is more in the whole GUI stuff

With the multi-gui I had the same idea last week, I tried something with a function like GUICreateChild and later with an array to save the normal window- and the parent-window-handle...

So if I clicked a control the the array would search trough and if the control window handle is the same like the normal window handle I had the parent window (gui) handle...

But I gave up the thing to extend the treeview-control and menu things with icons...

What I forget: how do you want the GUI-window-handle to implement int the control-commands?

with something like: GUIControlSet(wndhandle,type,text,....)

Ok, for the other commands I think it's not really needed ( I mean not GUIShow and GUIHide and maybe GUIRead- and Write) - GUIControlSetState and so on...

But only if you have an idea now how it could be...

So long...

Regards Holger

<{POST_SNAPBACK}>

I am prepare that what i understand that we will implement

• GUICreate ( "title", width, height, [left, top [,style [,exStyle]]] )
• GUIDelete ( )

• GUISetHelp ( file )
• GUISetBkColor( color )
• GUISetIcon ( [file] )
• GUISetFont ( size [,weight [,fontname [,attribute]]] )
• GUISetCoord ( left, top [,width [,height]] )
• GUISetCursor ( [cursorId] )
• GUISetState ( flag [,timeout]) ; replace GuiShow, GuiHide and handles trayicon extension

  flag can be @SW_SHOW, @SW_HIDE, @SW_MINIMIZE, @SW_RESTORE, @SW_FLASHTRAYICON, @SW_SHOWTRAYICON, @SW_HIDETRAYICON

• GUISetTrayTip ( tooltip )
• GUISetTrayBalloon ( "title", "text" [,timeout [,iconoption]] )
• GUISetTrayIcon ( filename [,iconid])

• GUIGetCursorPos ( )

• GUISetGroup ( )

• GUIControlSetXXX ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUIControlSetText ( controlid,text[,mode])
• GUIControlSetPos ( controlid, left, top [,width [,height] )
• GUIControlSetStyle ( controlid, style [,exStyle] )

• GUIControlSetBitmap ( controlid, filename)
• GUIControlSetIcon ( controlid, filename [,iconid [,mode]])
• GUIControlSetSmallIcon ( controlid, filename [,iconid [,mode]])

• GUIControlSetState ( controlid, state)
• GUIControlSetLimit ( controlid, max [,min])
• GUIControlSetResizing ( controlid, resizing)
• GUIControlSetBkColor ( controlid, backgroundcolor)
• GUIControlSetColor ( controlid, textcolor)
• GUIControlSetTip ( controlid, tiptext)
• GUIControlSetFont ( controlid, size [,weight [,fontname [,attribute]]])
• GUIControlSetData ( controlid, data [,default] )
• GUIControlSetNotify ( controlid [,action] )

• GUIWaitClose ( [timeout] )
• GUIGetMsg ( [timeout] ) ; replace GUIMsg() and GUIMsg (timeout)
• GUIPeekMsg ( ) ; replace GUIMsg(0)

• GUIRead ( [controlid] )
• GUIRecvMsg ( controlid ,msg [,wParam [,lParamType])
• GUISendMsg ( controlid, msg ,wParam, lParam )

Where XXX can be Label, Button, Checkbox, Radio, Combo, List, Pic, Avi, Icon, Edit, Input, Updown, Date, Progress, Tab, Tabitem, TrayMenu, ContextMenu, Menu, Menuitem, TreeView, TreeViewItem

for the question about wndhandle I think a GUISwitch(whandle) with whandle return by GUICreate will be OK without adding an extra parameter.

double check I did'nt forget a function

[Holger]

Ohhh I just thought, the new functions will be 'renamed'/called GUIControlSet-Text, -Color, -Data ...

I don't know - a little bit confused I'm now

Sorry....now I understand, the other functions (GUISet...) are for the GUI itself

Edited September 6, 2004 by Holger

[Holger]

I agree with Larry....

Yeah, and what else would good, if the helpfile under "GUI" has like sub-items, so that you don't have to scroll up and down for everything ;-)

Maybe:

GUI

|-----Control

|-----Window

Edited September 6, 2004 by Holger

[jpm]

GUIControlSetXXX ( "text", left, top [,width [,height [,style [,exStyle]]] )

should probably be

GUIControlCreateXXX ( "text", left, top [,width [,height [,style [,exStyle]]] )

or...

GUICreateGUI(...)

GUICreateControl("type"...)

(like FileFindNextFile File is iterated twice))

Lar.

<{POST_SNAPBACK}>

I am OK with GUIControlCreateXXX

[Valik]

The only thing I see is I don't think GuiMsg(0) should be renamed to GuiPeekMsg(). The reason being, its confusing for somebody with a Windows background. Peeking at a message does not remove it from the queue. Currently, GuiMsg(0) does remove it from the queue. However, if GuiGetMsg() is non-blocking (i.e. AdLib and hotkeys can still fire), then GuiPeekMsg() can truly be a peeker instead of a getter.

Edit: There is one other thing I have a gripe about. I don't think enabling/disabling a control should affect it's shown/hidden state. For example:

$c = GuiSetControl()
GuiSetControlEx($c, $GUI_HIDE)
GuiSetControlEx($c, $GUI_DISABLE)
; The control is now disabled, but is no longer hidden!

Obviously, that's a dumb example. But in the real world, it's possible to want a hidden control, but also want to change it's enabled/disabled state without showing the control (When setting a range of controls, for example, where controls can dynamically be visible/hidden based on run-time conditions). For this reason, I propose that GuiControlSetState() be remove and a more specific GuiControlShow([bool show]) and GuiControlDisable([bool disable]) be added where the argument is (obviously) non-zero to show/disable and 0 to hide/enable.

Edited September 6, 2004 by Valik

[Holger]

@Valik : do you also have ideas for the states: FOCUS, CHECKED, UNCHECKED and DEFBUTTON?

And I didn't use in the past more commands then one to set the state of a control - I summed it up like:

GUISetControlEx(controlid, $GUI_SHOW + GUI_DISABLE)

I would use also GUIControlSetState to set/show a tray-icon.

Ok, we have now a lot of control-commands but if there will be more and more - so it will be very funny :| to write scripts with GUI-functions.

What I mean is you have to split the scripts cause otherwise they will be so overloaded that you or another person who wants to understand your scripts is not able to to this...

So I don't know why it is so important to have all the same commands like the "ControlCommands"!?

As you said "I don't think enabling/disabling a control should affect it's shown/hidden state." -> I would fully agree with you.

But I think we should doing it by the ControlSetState-function.

We will see what others think...

Regards Holger

P.S. a great thing then would be if then somebody could write a translator to change your gui-scripts from old to new

Edited September 6, 2004 by Holger

[Valik]

Well, setting one state shouldn't affect non-related states. If GuiControlSetState() can not mess with things like that, then I can live with that, I guess. Quite honestly, I'd forgotten about focus and default button. It may also be beneficial to have a "default" state which clears hidden/disabled or something.

[CyberSlug]

P.S. a great thing then would be if then somebody could write a translator to change your gui-scripts from old to new

I've thought that the entire time I've followed this thread

If motivated, I could write simple conversions (for GUI's generated with AutoBuilder) but nothing too complex.....

[jpm]

The only thing I see is I don't think GuiMsg(0) should be renamed to GuiPeekMsg().  The reason being, its confusing for somebody with a Windows background.  Peeking at a message does not remove it from the queue.  Currently, GuiMsg(0) does remove it from the queue.  However, if GuiGetMsg() is non-blocking (i.e. AdLib and hotkeys can still fire), then GuiPeekMsg() can truly be a peeker instead of a getter.

Edit: There is one other thing I have a gripe about.  I don't think enabling/disabling a control should affect it's shown/hidden state.  For example:

$c = GuiSetControl()
GuiSetControlEx($c, $GUI_HIDE)
GuiSetControlEx($c, $GUI_DISABLE)
; The control is now disabled, but is no longer hidden!

Obviously, that's a dumb example.  But in the real world, it's possible to want a hidden control, but also want to change it's enabled/disabled state without showing the control (When setting a range of controls, for example, where controls can dynamically be visible/hidden based on run-time conditions).  For this reason, I propose that GuiControlSetState() be remove and a more specific GuiControlShow([bool show]) and GuiControlDisable([bool disable]) be added where the argument is (obviously) non-zero to show/disable and 0 to hide/enable.

<{POST_SNAPBACK}>

There is a bug today in the state setting because If you say $GUI_ENABLE it reset the hide/show without doing anything. So we will correct it as you suggest.

For peeking/removing I choose the name similar to windows API which peek but definitly give the choice to remove or not. I suggest we keep GuiGetMsg() blocking as it is in Windows and find another name for the peek with removal GUICheckMsg no confusion with Windows a little less clearer.

[Holger]

Yesterday I started to write/change the small functions

GUIControlSetBitmap, GUIControlSetIcon, GUIControlSetSmallIcon and GUIControlSetColor

But now I only start to implement again the menu-functions to the GUI so maybe we can/could use icons on menus and other items...

Edited September 8, 2004 by Holger