GUI Dev Stuff

[Jon]

This is looking much harder than I first thought as it affects virtually all interactions with controls. What I have done is deleted all code and I am creating Guibox.cpp from scratch. I will try and get a basic gui and button system working on multiple guis and when that is working start copying the old code function by function across to the new system. Nightmare. Some things (like tray icons) will need some serious thinking about. Most things should keep the new syntax, it's just internal problems this time...

I'll post code and updates as I do them as it will need a lot of testing maybe some help too.

Hopefully by starting again I can make some space/efficiency savings...so not all bad.

Edited September 23, 2004 by Jon

[Valik]

Jon, maybe adding an optional parameter to the end of GuiCreate() that takes some bit-or'd options. For example:

No taskbar entry = 1

No tray icon = 2

As Child = 4

I also think that some way of having wParam- and lParam-like functionality along with a message would be very useful. For example, take a menu, no matter what item is clicked, the original menu message is sent. It contains an lParam which is the index to which individual item was selected. Or with a tab control, the original tab object message is sent with an lParam of the new tab getting focus and a wParam of what tab is losing focus (Currently, you have to trap the tab's message, then do a SendMessage in your script to figure out where focus is going).

I think these two would both help in a multi-GUI environment because they offer more explicit control.

Edit: One method for implementing wParam/lParam is to have GuiGetMsg() take an optional flag which changes the return value from just a single message to an array of 0=msg, 1=lParam, 2=wParam or something similar (Default is current method). If I understood Holger correctly, each menu item or list-item takes up a control reference. The ability to retrieve those as parameters to a message would eliminate that.

Edited September 23, 2004 by Valik

[CyberSlug]

If you have to re-code tray icon stuff, would it be possible to have the "Script Paused" option appear on its menu?

[Jon]

This is turning up lots of odd bugs, the way backgrounds are set doesn't work in multigui mode for a start - you change one gui's background and they all change (because they use the same class). Which means that any other code that relies on setclasslong stuff will fail too. Well, I'll just smash it down and let someone else pick up the pieces I think

[Jon]

Ooooo I've got up to 1024 (silly I know) windows working with 2 buttons on each. This is a real bitch to convert but it's taking shape nicely.

Going to have to intially cut some stuff (all the tray icon gui stuff) because it currently doesn't work/make sense when you have multiple windows/taskbar entries. Once the basic stuff is up and running we can go back to this bit.

The big change is the GuiCreate function has a new parameter at the end, if you specify another window then the new window becomes a child of that window. This allows you to have as many parents/children as you want (A parent window has a taskbar entry and it's children always appear on top of it, when the parent is closed/minimized/etc then the children are too).

I've also made the memory more dynamic, so if you don't use any gui features then no memory is used, but each time you GuiCreate a new "window" structure is created that is able to hold 1024 controls. When the window is deleted all memory is released.

Should be able to show something off today, but it is slow work

Edited September 24, 2004 by Jon

[SlimShady]

1024 different controls!

If you have 10 tabs, you can have 100 controls in each tab.

Wow, that's more than enough!

I like this:

The big change is the GuiCreate function has a new parameter at the end, if you specify another window then the new window becomes a child of that window. This allows you to have as many parents/children as you want (A parent window has a taskbar entry and it's children always appear on top of it, when the parent is closed/minimized/etc then the children are too).

A situation:

If AutoIt3 is extracting info and you minimize the window.

When it's done, it'll show a (child) dialog that it's finished.

Will that (child) dialog show itself immediately or until the user restores the main window?

Edit: quote instead of code

Edited September 24, 2004 by SlimShady

[Jon]

If AutoIt3 is extracting info and you minimize the window.

When it's done, it'll show a (child) dialog that it's finished.

Will that (child) dialog show itself immediately or until the user restores the main window?

No idea. It will follow whatever rules windows places on stuff like this - you'll just have to try when it's working.

[SlimShady]

No idea.  It will follow whatever rules windows places on stuff like this - you'll just have to try when it's working.

<{POST_SNAPBACK}>

Allrighty then.

Thanks for everything

[Jon]

Heh, just received my first -3 event from GuiGetMsg() and then I went "hey, genius, how do you know which window that came from?"

So should I get GuiGetMsg to return an array?

$msg[0] = ControlID or Event (closed, minimized etc)

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

$msg[2] = Control handle

Or something? Or maybe have parameters for GuiGetMsg() so that without parameters it just returns the ControlID (like now) and then you can have different parameters if you want different levels of information. Maybe it should always return an array just so that it becomes "normal".

The only other solution I could think of would be to leave GuiGetmsg as is and have a new GuiGetLastMsgInfo or something that gives you extended information about the last event recevied.

Edit: I am sooo glad I upgraded the Variants so they can handle window handles, this would have been even more difficult otherwise.

Edited September 24, 2004 by Jon

[Valik]

I would vote to have it take a paramter. Default to what it does now, pass a 1 or something to get an array with more information.

[SlimShady]

I would vote to have it take a paramter.  Default to what it does now, pass a 1 or something to get an array with more information.

<{POST_SNAPBACK}>

I concur.

[jpm]

perhaps the whole checking will be simplify if we us a callback by control

GUISetCallBack(controlid, "function")

no more need to worry in the loop.

I did an implementation on current version adding a GuiSetCallBackReturn to have the "function" returning whatever it wants

I am not sure to understand where the control handle will be use.

[Jon]

perhaps the whole checking will be simplify if we us a callback by control

GUISetCallBack(controlid, "function")

no more need to worry in the loop.

I did an implementation on current version adding a GuiSetCallBackReturn to have the "function" returning whatever it wants

I am not sure to understand where the control handle will be use.

I'm currently thinking that callbacks will be nice a extra for simple boxes - i can imagine them getting far too complicated for anything more than a few controls.

This is what I have working at the moment, just to give you an idea of how it will work. I got most of the really difficult stuff done yesteday so progress should be good today.

expandcollapse popup

#include <GUIConstants.au3>

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

$parent1 = GuiCreate("Parent1")
GuiSetBkColor(0xCCCCFF)
$ok1 = GUICtrlCreateButton ("OK",  10, 30, 50)
$cancel1 = GUICtrlCreateButton ( "Cancel",  0, -1)
$label1 = GuiCtrlCreateLabel("My label!", 0, -1)
GuiCtrlSetColor(-1, 0xffffff)
GuiCtrlSetBkColor($label1, 0x0000ff)
GuiSetState(@SW_SHOW)

$parent2 = GuiCreate("Parent2", -1, -1, -1, -1, BitOr($WS_OVERLAPPEDWINDOW, $WS_SIZEBOX))
GuiSetBkColor(0xFFCCCC)
GuiSetCursor(4)
$ok2 = GUICtrlCreateButton ("OK",  10, 30, 50)
$cancel2 = GUICtrlCreateButton ( "Cancel",  0, -1)
GuiSetState(@SW_SHOW)

$childof1 = GuiCreate("Child of Parent1", -1, -1, -1, -1, -1, -1, $parent1)
GuiSetBkColor(0xDDDDFF)
$ok3 = GUICtrlCreateButton ("OK",  10, 30, 50)
$cancel3 = GUICtrlCreateButton ( "Cancel",  0, -1)
GuiSetState(@SW_SHOW)

; Check font stuff
GuiCtrlSetFont($ok1, 12)


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

; Only close if the X was clicked on parent1
  If $msg[0] = -3 and $msg[1] = $parent1 Then ExitLoop

wend

Edited September 25, 2004 by Jon

[Valik]

Jon, the only thing I think callbacks will do is make the script seem a little less like a program when looking at it. Instead of seeing the correlation between event/response in the form of a case structure, the event triggers the response behind the scenes. It's very MFC-like since it creates the same illusion that MFC does in it's bloated-fat-chick OOP way.

[Jon]

Send all hate mail to Valik...

[Jon]

I wanted to finish this off today (the coding part) but I need to go out in a while

Here is the first attempt. Most things should work but almost every line has been altered so post any bugs.

http://www.autoitscript.com/autoit3/files/...e/autoit/multi/

Added:

GuiSwitch ( windowhandle )

Functions removed:

GUICTRLSETNOTIFY

Functions I ran out of time with and don't work properly/at all:

GUICTRLSETIMAGE (on Treeviews)

GUIGETCURSORPOS

GUICTRLCREATETRAYMENU

GUISETTRAYBALLOON

GUISETTRAYICON

GUISETTRAYTIP

See the example file for the basics of multi usage.

I've got a feeling that the treeview/menu stuff has some bugs too (some odd use of unions there Holger...)

Edited September 25, 2004 by Jon

[Jon]

Dev stuff:

New "unions".

A couple of unions were added in the recent syntax change:

union 
{
    HWND    hWnd;
    HMENU   hMenu;
    HTREEITEM hItem;
};

Now, IMHO you should only access these unions _after_ checking the .cType of the control so that you are sure you get an expected value. I know that those datatypes above are the same "size" so that you can actually read like this:

tvItem.hItem        = (HTREEITEM)lpCtrl->hWnd;

But I think that is unsafe, from what I've read unions should not be used or relied upon for conversions like that. In the example above the datatypes are pointers and it's possible they are not the same size (or may not be the same size in the future.

I'm going to change the code that accesses these and put some checks in. Also hBuddy and hTip are in a union - is it not possible that a buddy control could also have a tip?

Edited September 26, 2004 by Jon

[jpm]

Dev stuff:

New "unions".

A couple of unions were added in the recent syntax change:

union 
{
    HWND    hWnd;
    HMENU    hMenu;
    HTREEITEM hItem;
};

Now, IMHO you should only access these unions _after_ checking the .cType of the control so that you are sure you get an expected value.  I know that those datatypes above are the same "size" so that you can actually read like this:

tvItem.hItem        = (HTREEITEM)lpCtrl->hWnd;

But I think that is unsafe, from what I've read unions should not be used or relied upon for conversions like that.  In the example above the datatypes are pointers and it's possible they are not the same size (or may not be the same size in the future.

I'm going to change the code that accesses these and put some checks in.  Also hBuddy and hTip are in a union - is it not possible that a buddy control could also have a tip?

<{POST_SNAPBACK}>

I fully agree for the checking that the reason I ask holger to find the incoherency.

for hBuddy/hTip it as intentional because the "updown" control using hBuddy will never has a hTip

[Jon]

I've just created a updown that has a different tip for the input and a tip for the up/down arrows So i'll seperate them.

Anyone tested the multi version yet? Does it seem OK? I'm just doing some more changes now and then I'll upload it and the source so you can have a look and readd/fix anything I've missed or broken.

I'll have to post a description of the changes too and the crazy things you will see in the source (GUIWINDOW *, GUICONTROL *, WinIdx and CtrlIdx and GlobalIDs - mwuahaha).

Edited September 26, 2004 by Jon

[Jon]

Uploaded again with some fixes into the "multi" directory.