Jump to content

v3.0.103 Unstable - Reloaded


Jon
 Share

Recommended Posts

  • Administrators

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.

Link to comment
Share on other sites

  • Replies 220
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

  • Administrators

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

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

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

  • Administrators

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.

Link to comment
Share on other sites

@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
Link to comment
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!
Link to comment
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:

Link to comment
Share on other sites

  • Administrators

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

  • Administrators

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

  • Administrators

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

  • Administrators

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

  • Administrators

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

Updated the unstable with a few code/example/doc changes.

Also changed the GuiCtrlSetCallback function to GuiCtrlSetOnEvent().

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...