Jump to content

GUI Changes Needed


Recommended Posts

  • Replies 133
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

@SlimShady: that is what I meant :( (ok, it's not confusing for me :ph34r: 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 by Holger
Link to post
Share on other sites

@SlimShady: that is what I meant :( (ok, it's not confusing for me :ph34r: 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. :">

Link to post
Share on other sites

@jpm: sounds very interesting :ph34r: yeah...really :(

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

It's remember me on the good 'old' Au3GUI from Larry :lol: 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 :lol:

Edited by Holger
Link to post
Share on other sites

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.

Link to post
Share on other sites

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 :ph34r:

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

Edited by Holger
Link to post
Share on other sites

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).

Link to post
Share on other sites
  • Administrators

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!

Link to post
Share on other sites

@Jon: ok :ph34r: 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 by Holger
Link to post
Share on other sites

@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 :lol:

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 :ph34r:

Link to post
Share on other sites

Ohhh :lol: 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 :lol:

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

Edited by Holger
Link to post
Share on other sites

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 by Holger
Link to post
Share on other sites

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
Link to post
Share on other sites

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 by Valik
Link to post
Share on other sites

@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 :ph34r:

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 by Holger
Link to post
Share on other sites

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.

Link to post
Share on other sites

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 :ph34r:

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

Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
Link to post
Share on other sites

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. :ph34r:

Link to post
Share on other sites

Yesterday I started to write/change the small functions

GUIControlSetBitmap, GUIControlSetIcon, GUIControlSetSmallIcon and GUIControlSetColor :ph34r:

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 by Holger
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...