Sign in to follow this  
Followers 0
Jon

v3.0.103 Unstable - Reloaded

221 posts in this topic

Last topic was getting massive, so started a new one :ph34r:

http://www.autoitscript.com/autoit3/files/unstable/autoit

I've updated the unstable code with the multi window GUI modifications. Major differences to the last version are:

- Multiple windows are possible

- GuiCtrlSetNotify and the related Opt() setting are gone. All controls now notify.

- GuiWaitClose removed

- All the GUI tray icon menus/minimize to type code has been removed until we can work out how best to implement this with multi windows

- Extra option available for GuiGetMsg() that cause it to return extra information in an array, this includes mouse details, window details, control details

- GuiConstants.au3 updated with GUI_EVENT_nnnn constants - use these and NOT the hardcoded magic numbers (like -3 for close).

The docs are not up to date yet so best to check the example (multi_gui.au3) in the unstable directory that shows most of the above, and to ask questions on here.

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

Oh yeah, if you use GuiGetMsg(1) then you get an array that looks like:

msg[0] = Event (GUI_EVENT_CLOSE, Control ID etc)

msg[1] = Window handle that the event came from

msg[2] = Control handle (if applicable)

msg[3] = X position of mouse movement/click (if applicable)

msg[4] = Y position of mouse movement/click (if applicable)

At the moment msg[3] and msg[4] are only used for the events:

GUI_EVENT_MOUSEMOVE

GUI_EVENT_PRIMARYDOWN

GUI_EVENT_PRIMARYUP

GUI_EVENT_SECONDARYDOWN

GUI_EVENT_SECONDARYUP

The full list of events:

$GUI_EVENT_CLOSE

$GUI_EVENT_MINIMIZE

$GUI_EVENT_RESTORE

$GUI_EVENT_MAXIMIZE

$GUI_EVENT_PRIMARYDOWN

$GUI_EVENT_PRIMARYUP

$GUI_EVENT_SECONDARYDOWN

$GUI_EVENT_SECONDARYUP

$GUI_EVENT_MOUSEMOVE

The only thing you should assume about the value of these events is that they are negative numbers. But you should NOT rely on the fact that you happen to know that GUI_EVENT_CLOSE = -3 as I may be changing the values in future.

Edited by Jon

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

Great!! Thanks.

EDIT: Ok. BTW, this was my question. :ph34r:

msg[0] = Event (GUI_EVENT_CLOSE, Control ID etc)
msg[1] = Window handle that the event came from
msg[2] = Control handle (if applicable)
msg[3] = X position of mouse movement/click (if applicable)
msg[4] = Y position of mouse movement/click (if applicable)
Edited by josbe

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

Yep, really great :lol:

BTW: maybe we should use only one trayicon for all things and (child)windows.

So the most programs/utils which are outthere has only 1 trayicon and so 1 traymenu...

We will see.

The last days I thought about an option like "GUITrayMenuOverride" to use the original traymenu ie.e as addition or use an own menu :(

We will see.

At the moment I can only say: great developement (that rocks) :lol::D

Regards Holger :ph34r:

Edited by Holger

Share this post


Link to post
Share on other sites

Yep, really great :D

BTW: maybe we should use only one trayicon for all things and (child)windows.

So the most programs/utils which are outthere has only 1 trayicon and so 1 traymenu...

We will see.

The last days I thought about an option like "GUITrayMenuOverride" to use the original traymenu ie.e as addition or use an own menu :lol:

We will see.

At the moment I can only say: great developement (that rocks) :D :D

Regards Holger :(

Thanks, I felt guilty about taking out the tray icon stuff that you did :ph34r: But the treeview stuff and menus are great once I understood how they worked :lol:

I think one gui-controlled tray icon and context menu would be good. I still can't see a solution about the minimize to tray thing. There can now be multiple parent windows so it doesn't really work. Maybe we'll just have to leave that feature out.

One thing I do want to look at is control specific context menus. So you right click on a control and instead of getting the GUI wide context menu you get a control specific menu.

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

@Jon: that would be a great thing I think :lol::(

So now I will play a little bit around with the 'new' GUI :ph34r:

...

P.S. I will look if there are a program with the situation (more (child)windows and automatically minimize to tray)

Edited by Holger

Share this post


Link to post
Share on other sites

Is GUI-to-GUI communication going to remain this easy?! :(:lol::ph34r:

#include "GUIConstants.au3"

$parent1 = GuiCreate("Parent1", 300, 200, 10, 10)
$button1 = GUICtrlCreateButton ("OK",  10, 30, 150)
GuiSetState(@SW_SHOW)

$parent2 = GuiCreate("Parent2", 300, 200, 350, 250)
$button2 = GUICtrlCreateButton ("OK",  10, 30, 150)
GuiSetState(@SW_SHOW)

While 1
    $msg = GuiGetMsg()  ; Get extra info in an array

   If $msg = $GUI_EVENT_CLOSE Then
      ExitLoop    ; close both windows at the same time
   ElseIf $msg = $button1 Then
      GuiCtrlSetData($button2, "Detected parent1 button click")
      GuiCtrlSetData($button1, "OK")
   ElseIf $msg = $button2 Then
      GuiCtrlSetData($button1, "Detected parent2 button click")
      GuiCtrlSetData($button2, "OK")
   EndIf
Wend

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

Share this post


Link to post
Share on other sites

Great Jon,

Just update txt2htm.au3 next time :ph34r:

Share this post


Link to post
Share on other sites

Looking at this post seems to me that it could be useful that GuiSetState can have an extra parameter to choose the GUI you want to change the state without being forced to call a GUISwitch or the default of the GUISetState should refer to the the GUI where the control was changed.

I don't think we need this extra parameter for other GUISet...

:ph34r:

Share this post


Link to post
Share on other sites

Is GUI-to-GUI communication going to remain this easy?! :(:lol::ph34r:

#include "GUIConstants.au3"

$parent1 = GuiCreate("Parent1", 300, 200, 10, 10)
$button1 = GUICtrlCreateButton ("OK",  10, 30, 150)
GuiSetState(@SW_SHOW)

$parent2 = GuiCreate("Parent2", 300, 200, 350, 250)
$button2 = GUICtrlCreateButton ("OK",  10, 30, 150)
GuiSetState(@SW_SHOW)

While 1
    $msg = GuiGetMsg()    ; Get extra info in an array

   If $msg = $GUI_EVENT_CLOSE Then
      ExitLoop    ; close both windows at the same time
   ElseIf $msg = $button1 Then
      GuiCtrlSetData($button2, "Detected parent1 button click")
      GuiCtrlSetData($button1, "OK")
   ElseIf $msg = $button2 Then
      GuiCtrlSetData($button1, "Detected parent2 button click")
      GuiCtrlSetData($button2, "OK")
   EndIf
Wend

It's pretty neat isn't it :lol: With the addition of callback stuff as well we should have everything we need for some nice mini-apps.

Share this post


Link to post
Share on other sites

Looking at this post seems to me that it could be useful that GuiSetState can have an extra parameter to choose the GUI you want to change the state without being forced to call a GUISwitch or the default of the GUISetState should refer to the the GUI where the control was changed.

I don't think we need this extra parameter for other GUISet...

:ph34r:

I agree. There are a couple of Gui function that could be improved with this ( GuiDelete() springs to mind)

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

I've updated the unstable added callback functionality - how does this look?

#include "GUIConstants.au3"

Opt("GUICoordMode",2)
Opt("GuiResizeMode", 1)

$parent1 = GuiCreate("Parent1")

$ok1 = GUICtrlCreateButton ("OK",  10, 30, 50)
GUICtrlSetCallback(-1, "OKPressed")

$cancel1 = GUICtrlCreateButton ( "Cancel",  0, -1)
GUICtrlSetCallback(-1, "CancelPressed")

GuiSetState(@SW_SHOW)


While 1
    $msg = GuiGetMsg(1)    ; Get extra info in an array
    If $msg[0] = $GUI_EVENT_CLOSE  Then ExitLoop
 
Wend


Func OKPressed()
    MsgBox(0, "OK Pressed", "ID=" & @GUI_CTRLID & " WinHandle=" & @GUI_WINHANDLE & " CtrlHandle=" & @GUI_CTRLHANDLE)
EndFunc

Func CancelPressed()
    MsgBox(0, "Cancel Pressed", "ID=" & @GUI_CTRLID & " WinHandle=" & @GUI_WINHANDLE & " CtrlHandle=" & @GUI_CTRLHANDLE)
EndFunc

The GuiGetMsg() is still required - it basically checks for events as usual and when it sees a control has notified it either returns a normal message or for controls with a callback defined it runs a function and sets the @GUI... values to useful things. I think it's pretty neat and gives us easy and advanced ways of working.

If you are going to use callbacks for most things you still need a general purpose message loop that handles the CLOSE/MINIMIZE type messages - but that's pretty easy to create a standard template for.

I think it's time I paid the docs some attention now. I hate documenting. :ph34r:

Edited by Jon

Share this post


Link to post
Share on other sites

Great job :ph34r:

Share this post


Link to post
Share on other sites

THanks Jon,

do you think we should kept the name GUICtrlSetCallBack?

What about GuiCtrlSetOnEvent? :(

We almost can put back the GuiWaitClose() with an asynchrous handling as in WinWaitClose :ph34r:

Share this post


Link to post
Share on other sites

THanks Jon,

do you think we should kept the name GUICtrlSetCallBack?

What about GuiCtrlSetOnEvent? :(

We almost can put back the GuiWaitClose() with an asynchrous handling as in WinWaitClose :ph34r:

Yeah OnEvent sounds better. I'll change it.

Share this post


Link to post
Share on other sites

#16 ·  Posted (edited)

Small bug in GuiSetFont

lpWin->sFont = szFont;
Edited by jpm

Share this post


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
Sign in to follow this  
Followers 0