[Solved!] Unexpected GUIGetMsg() / GUIGetMsg(1) Behavior

[Artisan]

I've been working on a fancy ListView for user input. When a cell is clicked, a temporary Combo or Input control is created. The user does their part, then the temporary control's data is transferred to the ListView and the temporary control is deleted. I'm quite pleased with how it's turned out, except for one puzzling "feature".

If I use "Switch GUIGetMsg()" in the main loop, then the first time a user clicks on the form causes a temp control to be both created and processed. That only occurs on the first click and not on any subsequent clicks. If I use "$msg = GUIGetMsg(1)" with a Switch command, it works properly on every click. See code below. I have no idea why this is. Does anyone else? I'll use GUIGetMsg(1) if I must, but I prefer my code to be as simple as possible.

expandcollapse popup

#include
#include
#include
#include
#include

Global Const $_INCL = 1, $_REGEX = 2, $_FILTER = 3
Global $h_TempCtrl, $TempCtrlStatus[3] = [False, -1, -1], $_ListViewY = 1
Switch @OSVersion
Case "WIN_2000", "WIN_XP", "WIN_XPe", "WIN_2003"
$_ListViewY = 0
EndSwitch

$h_GUI = GUICreate("Form1", 594, 329)
$h_ListView = GUICtrlCreateListView("#|Include or Not|Filter Type|Contents ", 24, 24, 545, 279, $LVS_SINGLESEL)
$hG_LVitem1 = GUICtrlCreateListViewItem("1.|Include|StringRegExp|", $h_ListView)
$hG_LVitem2 = GUICtrlCreateListViewItem("2.|Include|StringRegExp|", $h_ListView)
$hG_LVitem3 = GUICtrlCreateListViewItem("3.|Include|StringRegExp|", $h_ListView)
GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY")
GUIRegisterMsg($WM_COMMAND, "WM_COMMAND")
GUISetState(@SW_SHOW)

While 1
Switch GUIGetMsg()
;~ $msg = GUIGetMsg(1)
;~ Switch $msg[0]
Case $GUI_EVENT_CLOSE
Exit
Case $h_TempCtrl
If $h_TempCtrl <> 0 Then
_GUICtrlTemp_Apply("$h_TempCtrl")
EndIf
EndSwitch
WEnd

Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam)
#forceref $hWnd, $iMsg, $wParam
; Catch ListView messages
Local $hWndFrom, $iCode, $tNMHDR
$tNMHDR = DllStructCreate($tagNMHDR, $lParam)
$hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
$iCode = DllStructGetData($tNMHDR, "Code")
If $hWndFrom == GUICtrlGetHandle($h_ListView) And $iCode == $NM_CLICK Then _GUICtrlTemp_Create()
Return $GUI_RUNDEFMSG
EndFunc

Func WM_COMMAND($hWnd, $iMsg, $iwParam, $ilParam)
#forceref $hWnd, $iMsg
; Catch user input
Local $hWndFrom, $iIDFrom, $iCode
$hWndFrom = $ilParam
$iIDFrom = BitAND($iwParam, 0xFFFF)
$iCode = BitShift($iwParam, 16)
If $TempCtrlStatus[0] Then
If $hWndFrom == GUICtrlGetHandle($h_TempCtrl) Then
Switch $iCode
Case $CBN_SELENDOK
_GUICtrlTemp_Apply("$CBN_SELENDOK")
Case $CBN_SELENDCANCEL
_GUICtrlTemp_Delete("$CBN_SELENDCANCEL")
Case $EN_KILLFOCUS
_GUICtrlTemp_Apply("$EN_KILLFOCUS")
EndSwitch
EndIf
EndIf
Return $GUI_RUNDEFMSG
EndFunc

Func _GUICtrlTemp_Create()
; Create a temporary control for user input
Local $tempPos, $HitTest
$HitTest = _GUICtrlListView_SubItemHitTest(GUICtrlGetHandle($h_ListView))
If $HitTest[0] <> -1 Then
$TempCtrlStatus[0] = True
$TempCtrlStatus[1] = $HitTest[0]
$TempCtrlStatus[2] = $HitTest[1]
Switch $HitTest[1]
; Global Const $_INCL = 1, $_REGEX = 2, $_FILTER = 3, $_FREQ = 4
Case $_INCL
$tempPos = _GUICtrlListView_GetSubItemRect($h_ListView, $HitTest[0], $_INCL)
$h_TempCtrl = GUICtrlCreateCombo("", $tempPos[0] + 24, $tempPos[1] + 24 + $_ListViewY, $tempPos[2] - $tempPos[0], $tempPos[3] - $tempPos[1], $CBS_DROPDOWNLIST)
GUICtrlSetData($h_TempCtrl, "Include|Don't Include")
GUICtrlSetState($h_TempCtrl, BitOR($GUI_FOCUS, $GUI_ONTOP))
_GUICtrlComboBox_ShowDropDown($h_TempCtrl, True)
Case $_REGEX
$tempPos = _GUICtrlListView_GetSubItemRect($h_ListView, $HitTest[0], $_REGEX)
$h_TempCtrl = GUICtrlCreateCombo("", $tempPos[0] + 24, $tempPos[1] + 24 + $_ListViewY, $tempPos[2] - $tempPos[0], $tempPos[3] - $tempPos[1], $CBS_DROPDOWNLIST)
GUICtrlSetData($h_TempCtrl, "String|StringRegExp")
GUICtrlSetState($h_TempCtrl, BitOR($GUI_FOCUS, $GUI_ONTOP))
_GUICtrlComboBox_ShowDropDown($h_TempCtrl, True)
Case $_FILTER
$tempPos = _GUICtrlListView_GetSubItemRect($h_ListView, $HitTest[0], $_FILTER)
Local $hRegion = _WinAPI_CreateRectRgn($tempPos[0] + 24, $tempPos[1] + 24 + $_ListViewY, $tempPos[2], $tempPos[3])
$h_TempCtrl = GUICtrlCreateInput(_GUICtrlListView_GetItemText($h_ListView, $HitTest[0], 3), $tempPos[0] + 24, $tempPos[1] + 24 + $_ListViewY, $tempPos[2] - $tempPos[0], $tempPos[3] - $tempPos[1])
GUICtrlSetState($h_TempCtrl, BitOR($GUI_FOCUS, $GUI_ONTOP, $GUI_SHOW))
_GUICtrlEdit_SetSel($h_TempCtrl, 0, -1)
_WinAPI_RedrawWindow($h_GUI, 0, $hRegion, $RDW_UPDATENOW) ; It won't draw the control until mouse-out *** (WHY??)
EndSwitch
EndIf
EndFunc

Func _GUICtrlTemp_Apply( $caller )
; Apply the temporary control's text to the ListView
If $TempCtrlStatus[0] Then
$TempCtrlStatus[0] = False
_GUICtrlListView_SetItemText($h_ListView, $TempCtrlStatus[1], GUICtrlRead($h_TempCtrl), $TempCtrlStatus[2])
$TempCtrlStatus[1] = -1
$TempCtrlStatus[2] = -1
_GUICtrlTemp_Delete($caller & " -> Apply")
EndIf
EndFunc

Func _GUICtrlTemp_Delete( $caller )
ConsoleWrite("Delete called by: " & $caller & @LF & "$h_TempCtrl: " & $h_TempCtrl & @LF & @SEC & ':' & @MSEC & @LF & @LF)
; Get rid of the temporary control
GUICtrlDelete($h_TempCtrl)
EndFunc

Edited June 25, 2012 by Artisan

[Melba23]

Artisan,

Thanks for that - I enjoyed the detective work!

You need to set a placeholder value for $h_TempCtrl when you first declare it:

Global $h_TempCtrl = 9999 ; Or any other unlikely number

When a variable is undefined and used as a GUIGetMsg Case, it fires every time through the loop. So you always tested the Case $h_TempCtrl code as the value of $h_TempCtrl was undefined - AutoIt takes the undefined value as 0 which is the return of GUIGetMsg when the queue is empty. As a result this Case was being checked every few millisecs and as soon as you created the temporary control, the If $h_TempCtrl <> 0 condition was met and the _GUICtrlTemp_Apply function was run. It seems that the loop was so fast it actually used different values of the $h_TempCtrl within the same section of code - undefined to fire the Case and the correct ControlID for the If!

I hope that explanation is clear - please ask again if not.

M23

[Artisan]

It seems that the loop was so fast it actually used different values of the $h_TempCtrl within the same section of code - undefined to fire the Case and the correct ControlID for the If!

I hope that explanation is clear - please ask again if not.

M23

Ah. Thanks very much, Melba! That makes sense.

Oddly enough, I ran into an issue earlier with it calling GuiCtrlDelete twice using an old variable (which from AutoIt's perspective would have been different) and crashing because of it. I think it's due to how Windows handles its GUI function calls. Crazy, crazy Windows.

Edited June 25, 2012 by Artisan

[Melba23]

Artisan,

Glad I could help - and as I said it was good fun working out what was going on.

M23

[Artisan]

I tried using a string, but that gets interpreted as 0 from a numerical point of view.

Would it work to use a negative value too, like -1? I ask because -1 would be nice to use but it can also reference a prior control. I've tested it and it seems to work. I'm wondering if there would be any reason to suspect -1 could cause a problem.

[BrewManNH]

Have you tried it? Did it work? If you haven't tried it, try it and let us know.

Also, why bother with -1 instead of using something you know works as expected, contrariness?

[Melba23]

Artisan,

I'm wondering if there would be any reason to suspect -1 could cause a problem

Yes, system events are returned by GUIGetMsg as negative values - so you might still get the Case firing. The reason I used 9999 is that you are very unlikely () to have that many controls in your script and so that value will never be fired unintentionally by a GUIGetMsg return value.

M23

[Artisan]

I've tested it and it seems to work.

Have you tried it? Did it work? If you haven't tried it, try it and let us know.

Also, why bother with -1 instead of using something you know works as expected, contrariness?

Yes, I tried it. But my own tests don't necessarily cover every possibility. And I don't know enough about the way Windows handles messages to know that 9999 will always work. I'm not going to have anywhere near that many controls, so it should work. But my reasoning was to use something that will work instead of something that should work. Since GUIGetMsg() can return a negative value, I'll use GUIGetMsg(1) or I'll initialize to 9999.

EDIT - I'm wondering why GUIGetMsg(1) is different than vanilla GUIGetMsg(). Not that important, but it just seems odd. Maybe one processes variants and the other interprets everything as a number? Ooh! Does GUIGetMsg() ever return a decimal? There's all kinds of non-integers that would be guaranteed to work in that case.

Edited June 25, 2012 by Artisan

[Melba23]

Artisan,

You are overcomplicating things.

GUIGetMsg returns negative integers for system events and ControlIDs (positive integers) for GUI controls. So all you need to do is to set a placekeeper higher than the highest control you are likely to encounter - then you will never get that value returned by GUIGetMsg and your Case will never fire. I have used this technique for many scripts with complete success - why try and use decimals or strings when a suitably high integer does the trick?

M23

[Artisan]

Fair enough. This is never something I've had to deal with before, and if all goes well I'll post the finished product here. For that reason I want to make sure it'll work flawlessly and not glitch up now and then. But if you've never had a problem then I'd say that's pretty flawless. Especially since I have an idea how much code testing you do. Long time forum lurker, I am.

[Melba23]

Artisan,

to make sure it'll work flawlessly and not glitch up now and then

If that is your definition of success I would stop coding now! All code "glitches" now and again as the users find another way to get an unexpected input to be accepted.

If you want to be really clever, I would suggest resetting the placeholder value whenever you delete your temporary control - that way you will not get a GUIGetMsg return value even if you create other controls on the GUI subsequently.

M23

[Bowmore]

Another way to avoid uninitialized controls continuously firing is add a case o with a continue loop as the first case in a message loop. Something like this.

While 1
Switch GUIGetMsg()
    Case 0
        ContinueLoop
    Case $GUI_EVENT_CLOSE
        Exit
    Case $h_TempCtrl
        _GUICtrlTemp_Apply("$h_TempCtrl")
  EndSwitch
WEnd

[Artisan]

Artisan,

If that is your definition of success I would stop coding now! All code "glitches" now and again as the users find another way to get an unexpected input to be accepted.

Eh, that's true. On one of my larger coding projects, it was about half error-checking to prevent users from doing stupid things. But you know what they say - build an idiot-proof program...

Another way to avoid uninitialized controls continuously firing is add a case o with a continue loop as the first case in a message loop. Something like this.

That's a great solution! I really should have thought of that myself, but that's why this forum is here. We each have ideas that no one else does. I'm going to implement this!