GUI Changes Needed

[jpm]

Too shorten funtion name i want to propose to change GUIControl... to GUICtrl in the last proposal those function are pretty long (I am a very lazzy typewriter)

Even Holger miss some part in his last message ...

[Holger]

@jpm: I saw ...yeah, why not

GUICtrlCreate

GUICtrlSetIcon

GUICtrlSetState

I like the shorter functions instead of typing such a long like jpm said

Upd.: I tried it today in the morning with menus and icons but I will leave it at the moment( only normal menus), so I will work on the other functions

(((Maybe in the future it will be possible cause I think we have to use owner-draw menuitems...but this is another story )))

Edited September 8, 2004 by Holger

[CyberSlug]

Before I forget: Could the "updown" control be changed so that you do not need to explicitly declare an input control in addition to the up updown?

Hmm, I don't even see the updown stuff listed in the official docs

[Holger]

@CyberSlug: that is needed cause the "UpDown"-control is like an addon to a window-control, normally an edit-control.

Fact is that an "UpDown-control" can have styles and an "Edit-control" too.

So how would/could you split the different-styles?

Regards Holger

[CyberSlug]

@CyberSlug: that is needed cause the "UpDown"-control is like an addon to a window-control, normally an edit-control.

Fact is that an "UpDown-control" can have styles and an "Edit-control" too.

So how would/could you split the different-styles?

Regards Holger

<{POST_SNAPBACK}>

Good question.... I don't know :">

[jpm]

Before I forget:  Could the "updown" control be changed so that you do not need to explicitly declare an input control in addition to the up updown?

Hmm, I don't even see the updown stuff listed in the official docs

<{POST_SNAPBACK}>

True the official doc was missing on this control. This control must be link with an input control the second param define the controlid of the input control.

[Holger]

@JP: GUSetState for the GUI works so far.

I added 2 more macros:

@SW_MINIMIZETOTRAY,

@SW_NOFLASHTRAYICON and

@SW_RESETTRAYICON

So the tray functions should also work.

I renamed all control-create functions to:

GUICtrlCreateXXX

Today in the evening I will work a little bit more on it and send you all the modifications so far lately on sunday afternoon.

I hope that is ok.

Regards Holger

@all: the GUI-todolist is long, with the icons on menus and treeviewitems I will work later on...

Edited September 10, 2004 by Holger

[jpm]

@JP: GUSetState for the GUI works so far.

I added 2 more macros:

@SW_MINIMIZETOTRAY,

@SW_NOFLASHTRAYICON and

@SW_RESETTRAYICON

So the tray functions should also work.

I renamed all control-create functions to:

GUICtrlCreateXXX

Today in the evening I will work a little bit more on it and send you all the modifications so far lately on sunday afternoon.

I hope that is ok.

Regards Holger

@all: the GUI-todolist is long, with the icons on menus and treeviewitems I will work later on...

<{POST_SNAPBACK}>

I am almost thru the doc updating. I email you as soon as I am done.

Perhpas some impact on the code you are doing but we will on sunday night ...

[CyberSlug]

Fonts sizes should obey Windows' settings instead of being hard coded....

1) I have a user who must use the "High Contrast Black (extra large)" scheme in Windows. The GUI fonts do not automatically appear larger while MsgBox font and buttons do......

2) Is there any way to use dynamic colors.... For example, VisualBasic lets you create controls that have colors such as "ButtonFace" and "Highlight" which ajust to whatever color scheme the user set in Display Properties...

[jpm]

Fonts sizes should obey Windows' settings instead of being hard coded....

1)  I have a user who must use the "High Contrast Black (extra large)" scheme in Windows.  The GUI fonts do not automatically appear larger while MsgBox font and buttons do......

2)  Is there any way to use dynamic colors.... For example, VisualBasic lets you create controls that have colors such as "ButtonFace" and "Highlight" which ajust to whatever color scheme the user set in Display Properties...

<{POST_SNAPBACK}>

I understand the concern but I have no idea how to do that :">

[Holger]

@jpm: I read about the same 'problem' in another forum (c++ or vb) and there was an idea to get the settings with:

SystemParametersInfo-> SPI_GETNONCLIENTMETRICS and SPI_GETICONMETRICS

But I didn't have to think about it and how to do it...

Regards Holger

Edited September 15, 2004 by Holger

[jpm]

I just upload the GUI with the new syntax

The attached file give a synthesis of the changes.

You can download fromhttp://www.hiddensoft.com/fileman/users/jpm/AutoIt3-gui/

Happy GUI's

JP

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

• GUISetBkColor( color )
• GUISetCoord ( left, top [,width [,height]] )
• GUISetCursor ( [cursorId] )
• GUISetFont ( size [,weight [,attribute [,fontname]]] )
• GUISetHelp ( file )
• GUISetIcon ( iconfile [,iconid ] )
• GUISetTrayBalloon ( "title", "text" [,timeout [,iconoption]] )
• GUISetTrayIcon ( filename [,iconid])
• GUISetTrayTip ( tooltip )
• GUISetState ( [flag] ) ; replace GuiShow, GuiHide and handles trayicon extension

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

• GUIGetCursorPos ( )

• GUIStartGroup ( )

• GUICtrlCreateAvi ( filename, subfileid, left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateButton ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateCheckbox ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateCombo ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateContextMenu ( )
• GUICtrlCreateDate ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateEdit ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateGroup ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateIcon ( filename, iconid, left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateInput ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateLabel ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateList ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateMenu ( "submenutext" [,menuid [,menuentry]] )
• GUICtrlCreateMenuitem ( "text", menuid [,menuentry] )
• GUICtrlCreatePic ( filename, left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateProgress ( left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateRadio ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateTab ( left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateTabItem ( "text" )
• GUICtrlCreateTrayMenu ( )
• GUICtrlCreateTreeView ( left, top [,width [,height [,style [,exStyle]]] )
• GUICtrlCreateTreeViewItem ( "text", treeviewid )
• GUICtrlCreateUpdown ( inputcontrolid] )

• GUICtrlSetBkColor ( controlid, backgroundcolor)
• GUICtrlSetColor ( controlid, textcolor)
• GUICtrlSetData ( controlid, data [,default] )
• GUICtrlSetFont ( controlid, size [,weight [,attribute [,fontname]]])
• GUICtrlSetImage ( controlid, filename [,iconid [,mode]])
• GUICtrlSetLimit ( controlid, max [,min])
• GUICtrlSetNotify ( controlid [,action] )
• GUICtrlSetPos ( controlid, left, top [,width [,height] )
• GUICtrlSetResizing ( controlid, resizing)
• GUICtrlSetState ( controlid, state)
• GUICtrlSetStyle ( controlid, style [,exStyle] )
• GUICtrlSetTip ( controlid, tiptext)

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

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

[Valik]

The only thing I see I still don't like is the GuiMsg stuff. As Jon just said in another thread, GuiMsg(0) should be the only way to get messages. That means its the most useful, so it shouldn't be relegated to GuiPeekMsg().

Here is my suggestion:

• GuiGetMsg() = Current GuiMsg(0), just a name change, basically.
• GuiPeekMsg() = Identical to GuiGetMsg (Meaning it uses non-blocking code so hotkeys will work), EXCEPT it doesn't remove the message from the queue (Only GuiGetMsg() should do that).

The current GuiWaitClose(), GuiMsg(), GuiMsg(n) should all go away.

• GuiWaitClose() is just confusing. Its nice for your first ever GUI script, but then you have to completely start over learning GUI stuff to make anything interactive.
• GuiMsg() blocks which is not good. Honestly, who wants AdLib and Hotkeys disabled like this?
• GuiMsg(n), although convient, is used so seldom, if it's that critical to have, then just using TimerInit() before entering the main message pump and then poll the time elapsed with TimerDiff() and a pre-defined threshold.

That should simplify things both for the scripters and for the maintainers.

Aside from this issue, all the other changes look really nice, including all the new features.

[SlimShady]

Thanks jpm, Holger and Jon for the new changes, features.

I totally agree with Valik.

[jpm]

The only thing I see I still don't like is the GuiMsg stuff.  As Jon just said in another thread, GuiMsg(0) should be the only way to get messages.  That means its the most useful, so it shouldn't be relegated to GuiPeekMsg(). 

Here is my suggestion:

• GuiGetMsg() = Current GuiMsg(0), just a name change, basically.

• GuiPeekMsg() = Identical to GuiGetMsg (Meaning it uses non-blocking code so hotkeys will work), EXCEPT it doesn't remove the message from the queue (Only GuiGetMsg() should do that).

The current GuiWaitClose(), GuiMsg(), GuiMsg(n) should all go away. 

• GuiWaitClose() is just confusing.  Its nice for your first ever GUI script, but then you have to completely start over learning GUI stuff to make anything interactive.

• GuiMsg() blocks which is not good.  Honestly, who wants AdLib and Hotkeys disabled like this?

• GuiMsg(n), although convient, is used so seldom, if it's that critical to have, then just using TimerInit() before entering the main message pump and then poll the time elapsed with TimerDiff() and a pre-defined threshold.

That should simplify things both for the scripters and for the maintainers.

Aside from this issue, all the other changes look really nice, including all the new features.

<{POST_SNAPBACK}>

I think you speek GUIPeekMsg instead of GUIGetMsg and reverse.

But nevertheless if everybody (You and Jon) is happy with the removal of GuiWaitClose and GUIGetMsg, that's not a big deal to remove them.

Thanks for your nice comment on the other changes.

[Valik]

I think you speek GUIPeekMsg instead of GUIGetMsg and reverse.

But nevertheless if everybody (You and Jon) is happy with the removal of GuiWaitClose and GUIGetMsg, that's not a big deal to remove them.

Thanks for your nice comment on the other changes.

<{POST_SNAPBACK}>

No, JP, I'm not confusing them.

GuiGetMsg() should get the message from the message queue and remove it from the queue. It should do exactly what GuiMsg(0) currently does.

GuiPeekMsg() should do exactly what GuiGetMsg() does, except it should not remove the message from the queue.

The thing that makes it confusing is that with the Win32 GetMessage() function, control is never returned until a message is received, but with PeekMessage(), control is returned immediately, message or not. However, because of the need to allow AdLib/Hotkeys to work, it's necessary for our GuiGetMsg() function to return a bogus message immediately (0 in this case) just so it doesn't block. For all intents and purposes, a user shouldn't be able to tell the difference on blocking or non-blocking because they should only handle messages they need to, not 0 (And unless they know what they are doing, shouldn't have anything in their messag handler loop except for a Select/Case or If/ElseIf block checking the message to what they are expecting).

The fundamental difference between Getting and Peeking is that the message is not removed from the message queue when peeking. The fact that PeekMessage() returns immediately has nothing to do with the key difference between getting and peeking.

[jpm]

No, JP, I'm not confusing them. 

GuiGetMsg() should get the message from the message queue and remove it from the queue.  It should do exactly what GuiMsg(0) currently does.

GuiPeekMsg() should do exactly what GuiGetMsg() does, except it should not remove the message from the queue.

The thing that makes it confusing is that with the Win32 GetMessage() function, control is never returned until a message is received, but with PeekMessage(), control is returned immediately, message or not.  However, because of the need to allow AdLib/Hotkeys to work, it's necessary for our GuiGetMsg() function to return a bogus message immediately (0 in this case) just so it doesn't block.  For all intents and purposes, a user shouldn't be able to tell the difference on blocking or non-blocking because they should only handle messages they need to, not 0 (And unless they know what they are doing, shouldn't have anything in their messag handler loop except for a Select/Case or If/ElseIf block checking the message to what they are expecting).

The fundamental difference between Getting and Peeking is that the message is not removed from the message queue when peeking.  The fact that PeekMessage() returns immediately has nothing to do with the key difference between getting and peeking.

<{POST_SNAPBACK}>

I am more confuse but I can live with Autoit functions not working as the basic Window they wrap. I leave to the group the decision that "Get" can be a nonblocking function if it is coherent with AutoIT.

Thanks for your comments

[Jon]

Ok,

So I am thinking that we get rid of the GuiWaitClose and different sorts of GetMsg and just leave what was GuiMsg(0). The same goes for the notify modes, I think the default mode should be "notify" and not "close". Virtually every script I've seen posted start of with the option that turns notify on for all controls

With the different ways of using GetMsg gone the docs and usage could be simplfied so we basically say in the docs:

1. You create the GUI

2. You poll the gui using a message loop like this:

While 1

$code = GetMsg()

...

Wend

3. You close the GUI

Yeah, it would make a simple msgbox with a couple of controls and an OK button about 5 lines more complicated (a messageloop instead of a GuiWaitClose) but there would be no confusion over which way to do it and there has been a lot of confusion over it already - and that's just between the devs...

In addition to that lot I was pondering a new notify option that instead of sending a message code causes GetMsg to execute a specifed function - like the functions in VB that can be attached to buttons and things. Should be easy enough, but that's just a pondering.

Does that sound like a plan? JP/Holger, if this looks OK don't worry about updating anything, I'll do it. You've done lots of great work already to get things up and running and I don't want to impose. I'll _try_ and stay out of photoshop long enough to do it

[Jon]

Oh, and I am sure season is about over... fhew...

Lar.

I've been out on the bike about twice this year. For the last 2 or 3 months it has rained _every single day_ Only managed 2 BBQs as well before being rained on. Summer sucked this year. Sucked big time.

Edit: Oh, and no xbox tonight. It was Empire Strikes Back night

Edited September 21, 2004 by Jon

[jpm]

Ok,

So I am thinking that we get rid of the GuiWaitClose and different sorts of GetMsg and just leave what was GuiMsg(0).  The same goes for the notify modes, I think the default mode should be "notify" and not "close".  Virtually every script I've seen posted start of with the option that turns notify on for all controls

With the different ways of using GetMsg gone the docs and usage could be simplfied so we basically say in the docs:

1. You create the GUI

2. You poll the gui using a message loop like this:

While 1

  $code = GetMsg()

  ...

Wend

3. You close the GUI

Yeah, it would make a simple msgbox with a couple of controls and an OK button about 5 lines more complicated (a messageloop instead of a GuiWaitClose) but there would be no confusion over which way to do it and there has been a lot of confusion over it already - and that's just between the devs... 

In addition to that lot I was pondering a new notify option that instead of sending a message code causes GetMsg to execute a specifed function - like the functions in VB that can be attached to buttons and things.  Should be easy enough, but that's just a pondering.

Does that sound like a plan?  JP/Holger, if this looks OK don't worry about updating anything, I'll do it.  You've done lots of great work already to get things up and running and I don't want to impose.  I'll _try_ and stay out of photoshop long enough to do it

<{POST_SNAPBACK}>

I am OK for the simplification.

Perhaps we need to another one on the managing of the traytip,trayicon and the balloon

Thanks for support of our work