Msg return bug ?

[kjactive]

I noticed that msg 'extended' array returns changed durring last beta updates and autoit3 gui is sending a lot of 0x00000000 if nothing happens and that is bad as if one got an unintiated window or control this is also still addressed as 0x00000000

#include <GUIConstants.au3>

Global $MainW, $SecondW
$MainW = GUICreate('test',180,60,-1,-1,$WS_SIZEBOX)
GUISetState()
    
While 1
    $msg = GUIGetMsg(1); this msg[1] is sending a lot of 0x00000000 that correspond with a non initiated window as address also is 0x00000000
    Select
;Case $msg[1] = 0x00000000; walk around solution !!!!!!!!!
    Case $msg[1] = $SecondW; Second window
            ConsoleWrite('Second window hit' & @CR)
    Case $msg[1] = $MainW; First window
        ConsoleWrite('Main window hit' & @CR)
        Select
        Case $msg[0] = $GUI_EVENT_CLOSE
            ExitLoop
        EndSelect
    EndSelect
WEnd
Exit    

Func Windowtwo()
    $SecondW = GUICreate('test window 2',180,60,-1 + 200,-1,$WS_SIZEBOX)
    GUISetState()
EndFunc

This is a stripped down example!

This example msg 'extended' hits second window entry as it is still not initiated and ruin the script - is this a bug or wanted behave?

kjactive

Edited August 9, 2005 by kjactive

[jpm]

No change in this area.

It is normal that GUIGetMSG return 0 when there is no message so your script has no regression.

[kjactive]

What do I do with the script that get ruined, as all unitiated windows and controls ID is 0x00000000 too - was it not a god idear to suppress zeros from msg 'extended' in autoit3 gui support as these are of no use anyway ?

kjactive

[jpm]

What do I do with the script that get ruined, as all unitiated windows and controls ID is 0x00000000 too - was it not a god idear to suppress zeros from msg 'extended' in autoit3 gui support as these are of no use anyway ?

kjactive 

<{POST_SNAPBACK}>

read the doc this return 0 has never change. So it is NOT A BUG

[kjactive]

Yes I read that but why is this so as this return zero is of no use in my mind and it do ruin this example script - could it not be suppressed in some manner by autoit3 gui msg handle and it would speed up the runtime script handle too as there would be a lot of returns that the script do not has to handle in the select endselect area and what should I do with the script, a simple script with two windows do get ruined...

kjactive

Edited August 9, 2005 by kjactive

[Jon]

If it was supressed then GuiGetMsg would not return until there was something to return yes? If so then the entire program would halt until there was an event to read.

You have to read the $msg[0] entry before randomly reading $msg[1]

[kjactive]

Thanks for a insighter responce - I can see your point and maybe this is not the place for this discusion but...

As I understand, the msg zero returns, when nothing happens, is vital for several other autoit functions and the runtime process but I think that to read the $msg[0] entry before randomly reading $msg[1] is not the solution on larger scripts as there could be a lot to check before the script release the zero variable and that could slowdown the process - I think that I prefer to catch the zero variable at runtime startup like in my example walk around solution but autoit3 gui has a lack of missing a lot of vital Event IDs and I was wondering - these zero returns has only the porpose of keeping the autoit process running - why could they not be more usefull and return some real Event IDs that autoit misses that much - maybe even just all IDs that should be easy to attach and I think would not ruin the running process?

kjactive

[jpm]

I move this topic to support as it is not a BUG but a support action.