v3.0.103 Unstable - Reloaded

[Jon]

Last topic was getting massive, so started a new one

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.

[Jon]

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 September 27, 2004 by Jon

[Josbe]

Great!! Thanks.

EDIT: Ok. BTW, this was my question.

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 September 27, 2004 by josbe

[Holger]

Yep, really great

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)

Regards Holger

Edited September 27, 2004 by Holger

[Jon]

Yep, really great

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) :D

Regards Holger

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

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.

[Holger]

@Jon: that would be a great thing I think

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

...

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

Edited September 27, 2004 by Holger

[CyberSlug]

Is GUI-to-GUI communication going to remain this easy?!

#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

[jpm]

Great Jon,

Just update txt2htm.au3 next time

[jpm]

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

[Jon]

Is GUI-to-GUI communication going to remain this easy?!

#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 With the addition of callback stuff as well we should have everything we need for some nice mini-apps.

[Jon]

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

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

[Jon]

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.

Edited September 28, 2004 by Jon

[SlimShady]

Great job

[jpm]

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

[Jon]

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

Yeah OnEvent sounds better. I'll change it.

[jpm]

Small bug in GuiSetFont

lpWin->sFont = szFont;

Edited September 28, 2004 by jpm

[Jon]

Small bug in GuiSetFont

lpWin->sFont = szFont;

[Jon]

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

[Josbe]

Notify: "AutoIt3.exe" only have 36K.(unstable folder)

Edited September 28, 2004 by josbe

[Jon]

Notify: "AutoIt3.exe" only have 36K.(unstable folder)

That's what happens when you try and upload 2 megs of stuff over dialup....

Try again.