Problems using GuiRegisterMsg

[jimollerhead]

Hello Folks,

I'm not an AutoIt noob but I am new to the GuiRegisterMsg command.

What I am trying to do is to pop up a "long string edit" window when user double-clicks. Ideally I wanted it to be a duouble-click in the Input box itself but I couldn't get this to work so I was going to settle for a double-click *near* the input box.

Here's a severely curtailed version of my almost 1300-line script. From the msgbox "tell-tale" it appears that the GuiRegisterMsg definition interferes with the GuiGetMsg function and it 'remembers' the last GuiGetMsg return value -- is there some way to 'flush' the holding area? Note that there are bits in there from experiments -- if I comment out the While-Wend and replace it with the sleep line you can better see what I am trying to acheive. The list box is just to give a different kind of control than an input field to have the focus, it's contents are not relevant to the snippet, only to the full app.

All help gratefully acknowledged! Here's the code snippet:

expandcollapse popup

#include <WindowsConstants.au3>
#include <ButtonConstants.au3>
#include <GuiConstantsEx.au3>
#include <EditConstants.au3>
#include <ListBoxConstants.au3>
Dim $InputFileId
Dim $OutputFileId
Dim $winMain
Dim $GUIMsg
GUIRegisterMsg($WM_LBUTTONDBLCLK, "EditText")
$winMain = GUICreate ("Test for Editing Long Strings", 800, 560, -1, -1)
GUICtrlCreateLabel("File to Process", 22,30)
GUICtrlCreateLabel("Output File", 40,60)
$InputFileId = GUICtrlCreateInput ( "", 100, 25, 400, 20)
$OutputFileId = GUICtrlCreateInput ( "", 100, 55, 400, 20)
$btnInputFile = GUICtrlCreateButton ( "Browse for File", 520, 22, 110, 25)
$btnOPFolder = GUICtrlCreateButton ( "Browse for Location", 520, 53, 110, 25)
; Create the list of actions
$ActionList = GUICtrlCreateList( "", 25, 260, 70, 200)
GUICtrlSetData($ActionList, "Delete|Exclude|Include|Insert|Kill Blanks|Move|Remove|Replace|Switch", "Delete")
GUISetState(@SW_SHOW, $winMain)
While 1
$GUIMsg = GUIGetMsg()
Switch $GUIMsg
Case $GUI_EVENT_CLOSE
ExitLoop
Case $btnInputFile
MsgBox(0, "Info", "Input Button pressed")
Case $btnOPFolder
MsgBox(0, "Info", "Output Button pressed")
EndSwitch
WEnd
Func EditText($Window, $Caller, $p1, $p2)
Dim $winEdit
Dim $CtrlName
Dim $edtString
Dim $btnAccept
Dim $btnReject
Dim $Response
Dim $RetString
Dim $CtrlId
Dim $ActCode
Dim $HasFocus
$CtrlName = ControlGetFocus("Test for Editing Long Strings")
msgbox(0,"DOUBLE-CLICK!","Control: " & $CtrlId & @CRLF & "Action: " & $ActCode & @CRLF & "CtrlName: " & $CtrlName)
If StringInStr($CtrlName,"Edit") > 0 Then
$winEdit = GUICreate("Long String Editor", 790, 100, -1, -1, $WS_BORDER)
$edtString = GUICtrlCreateEdit("This is a potentially long string", 5, 5, 780, 20, $ES_AUTOHSCROLL)
$btnAccept = GUICtrlCreateButton( "Accept String", 240, 33, 100, 30)
$btnReject = GUICtrlCreateButton( "Reject String", 440, 33, 100, 30)
GUISetState(@SW_SHOW, $winEdit)
GUICtrlSetState($edtString, $GUI_FOCUS)
; sleep(5000)
;#cs
While 1
$Response = GUIGetMsg()
if $Response = $btnAccept Then
ExitLoop
EndIf
Select
Case $Response = $btnReject
     ExitLoop
Case $Response = $btnAccept
; GUICtrlSetData($CtrlName, $RetString)
     ExitLoop
Case Else
     $RetString = GUICtrlRead($edtString)
EndSelect
WEnd
;#ce
Else
Return $GUI_RUNDEFMSG
EndIf
GUICtrlSetData($CtrlName, $RetString)
GUIDelete($winEdit)
Return $GUI_RUNDEFMSG
EndFunc

Edited May 8, 2013 by jimollerhead

[guinness]

Well what sticks out is you have the message registered before the GUI is created. Also a couple of other points...

• Don't use Dim, try to use Local or Global exclusively. Read the help file as to why Dim can cause more issues than solve them
• Use [autoit][/autoit] tags when posting AutoIt code.

[jimollerhead]

Thanks for the quick reply Guinnes, but I don't think that's what my main problem was... I was doing too much in the EditText function (despite having read sevreal times in the Forum that you should "get in and out fast" when interrupting the messaging!

Here is an "almost there" version....my main problem now is detecting the field that had the focus when the double-click occurred. Using the ControlGetFocus function returns the CLASNN name which is useless for later when I want to copy the string back into the calling field because I need the internal ID then. I suspect I can get it by diddling around with the third parameter but the usual bitshifting that you use with WM_COMMAND doesn't work with WM_LBUTTONDBLCLK.... Here's the revised "almost there" version: (BTW I did try to use the 'AutoIT code' thing to paste last time but it just sat there and would not accept my mouse click) -- I'll research the "Don't use dim" thing if you can tell me what section of the helpfile it's in -- most examples use Dim and nothing says don't use it....

expandcollapse popup

#include
#include
#include
#include
#include

Dim $InputFileId
Dim $OutputFileId
Dim $winMain
Dim $GUIMsg
Dim $EditCtrlId
Dim $EditCtrlName
Dim $EditCtrlHandle
Dim $DoubleClick = False

GUIRegisterMsg($WM_LBUTTONDBLCLK, "DblClick")

$winMain = GUICreate ("Test for Editing Long Strings", 800, 560, -1, -1)
GUICtrlCreateLabel("File to Process", 22,30)
GUICtrlCreateLabel("Output File", 40,60)
$InputFileId = GUICtrlCreateInput ( "", 100, 25, 400, 20)
$OutputFileId = GUICtrlCreateInput ( "", 100, 55, 400, 20)
$btnInputFile = GUICtrlCreateButton ( "Browse for File", 520, 22, 110, 25)
$btnOPFolder = GUICtrlCreateButton ( "Browse for Location", 520, 53, 110, 25)
; Create the list of actions
$ActionList = GUICtrlCreateList( "", 25, 260, 70, 200)
GUICtrlSetData($ActionList, "Delete|Exclude|Include|Insert|Kill Blanks|Move|Remove|Replace|Switch", "Delete")
GUISetState(@SW_SHOW, $winMain)

While 1
$GUIMsg = GUIGetMsg()
Switch $GUIMsg
Case $GUI_EVENT_CLOSE
ExitLoop

Case $btnInputFile
MsgBox(0, "Info", "Input Button pressed")

Case $btnOPFolder
MsgBox(0, "Info", "Output Button pressed")
EndSwitch
If $DoubleClick Then
EditText()
EndIf
WEnd

Func DblClick($Window, $Caller, $p1, $p2)

$EditCtrlId = $p2 ; BitAND($p1, 0x0000FFFF)
$EditCtrlName = ControlGetFocus("Test for Editing Long Strings")
$EditCtrlHandle = ControlGetHandle("Test for Editing Long Strings", "", $EditCtrlName)
msgbox(0,"DOUBLE-CLICK!","Control: " & $EditCtrlId & @CRLF & "ControlName: " & $EditCtrlName & @CRLF & "Handle: " & $EditCtrlHandle)
$DoubleClick = True
Return $GUI_RUNDEFMSG
EndFunc

Func EditText()
Dim $winEdit
Dim $edtString
Dim $btnAccept
Dim $btnReject
Dim $Response
Dim $RetString

If StringInStr($EditCtrlName,"Edit") > 0 Then
$winEdit = GUICreate("Long String Editor", 790, 100, -1, -1, $WS_BORDER)
$edtString = GUICtrlCreateEdit("This is a potentially long string", 5, 5, 780, 20, $ES_AUTOHSCROLL)
$btnAccept = GUICtrlCreateButton( "Accept String", 240, 33, 100, 30)
$btnReject = GUICtrlCreateButton( "Reject String", 440, 33, 100, 30)
GUISetState(@SW_SHOW, $winEdit)
GUICtrlSetState($edtString, $GUI_FOCUS)

While 1
$Response = GUIGetMsg()
Select
Case $Response = $btnReject
ExitLoop
Case $Response = $btnAccept
GUICtrlSetData(5, $RetString)
; GUICtrlSetData($EditCtrlHandle, $RetString)
ExitLoop
Case Else
$RetString = GUICtrlRead($edtString)
EndSelect
WEnd
GUIDelete($winEdit)
EndIf
$DoubleClick = False
EndFunc

Edited May 8, 2013 by jimollerhead

[guinness]

http://www.autoitscript.com/autoit3/docs/keywords/Dim.htm

You should use Local or Global, instead of Dim, to explicitly state which scope is desired for a variable/constant/array.

Also 99% of the examples don't use Dim, if they did then they've been zapped in the latest beta version of the help file.

[jimollerhead]

OK thanks for the link...I was expecting some kind of performance-related reason rather than being too gormless to differentiate locals and globals without explicitly saying so. As I've been programming professionally with 3GLs since the early 80's (Basic then Pascal, the king of 3GLs, then C) I think I am OK to manage to make the differentiation unaided. I will, however take the advice for future AutoIt code if only to make it more readable for posting in the forum. My far more pressing issue is trying to identify the ID for the control that has the focus in my code!

Regards,

Jim.

[jimollerhead]

Sorted! Found this little beauty in a Forum example: _WinAPI_GetDlgCtrlID - Thank you, thank you, thank you, Authenticity!!

It effectively is just a converter that takes a handle in and spits an ID (i.e. what you get from the Create...statement) out!

Here's the finally working beast:

expandcollapse popup

#include <WindowsConstants.au3>
#include <ButtonConstants.au3>
#include <GuiConstantsEx.au3>
#include <EditConstants.au3>
#include <ListBoxConstants.au3>
#include <WinAPI.au3>
Global $InputFileId
Global $OutputFileId
Global $winMain
Global $GUIMsg
Global $EditCtrlId
Global $EditCtrlName
Global $EditCtrlHandle
Global $DoubleClick = False
$winMain = GUICreate ("Test for Editing Long Strings", 800, 560, -1, -1)
GUICtrlCreateLabel("File to Process", 22,30)
GUICtrlCreateLabel("Output File", 40,60)
$InputFileId = GUICtrlCreateInput ( "", 100, 25, 400, 20)
$OutputFileId = GUICtrlCreateInput ( "", 100, 55, 400, 20)
$btnInputFile = GUICtrlCreateButton ( "Browse for File", 520, 22, 110, 25)
$btnOPFolder = GUICtrlCreateButton ( "Browse for Location", 520, 53, 110, 25)
; Create the list of actions
$ActionList = GUICtrlCreateList( "", 25, 260, 70, 200)
GUICtrlSetData($ActionList, "Delete|Exclude|Include|Insert|Kill Blanks|Move|Remove|Replace|Switch", "Delete")
GUISetState(@SW_SHOW, $winMain)
GUIRegisterMsg($WM_LBUTTONDBLCLK, "DblClick")
While 1
$GUIMsg = GUIGetMsg()
Switch $GUIMsg
Case $GUI_EVENT_CLOSE
ExitLoop
Case $btnInputFile
MsgBox(0, "Info", "Input Button pressed")
Case $btnOPFolder
MsgBox(0, "Info", "Output Button pressed")
EndSwitch
If $DoubleClick Then
EditText()
EndIf
WEnd
Func DblClick($Window, $Caller, $p1, $p2)
; $EditCtrlId = $p2 ; BitAND($p1, 0x0000FFFF)
$EditCtrlName = ControlGetFocus("Test for Editing Long Strings")
$EditCtrlHandle = ControlGetHandle("Test for Editing Long Strings", "", $EditCtrlName)
$EditCtrlId = _WinAPI_GetDlgCtrlID($EditCtrlHandle)
msgbox(0,"DOUBLE-CLICK!","Control: " & $EditCtrlId & @CRLF & "ControlName: " & $EditCtrlName & @CRLF & "Handle: " & $EditCtrlHandle)
$DoubleClick = True
Return $GUI_RUNDEFMSG
EndFunc
Func EditText()
Local $winEdit
Local $edtString
Local $btnAccept
Local $btnReject
Local $Response
Local $RetString
If StringInStr($EditCtrlName,"Edit") > 0 Then
$winEdit = GUICreate("Long String Editor", 790, 100, -1, -1, $WS_BORDER)
$edtString = GUICtrlCreateEdit("This is a potentially long string", 5, 5, 780, 20, $ES_AUTOHSCROLL)
$btnAccept = GUICtrlCreateButton( "Accept String", 240, 33, 100, 30)
$btnReject = GUICtrlCreateButton( "Reject String", 440, 33, 100, 30)
GUISetState(@SW_SHOW, $winEdit)
GUICtrlSetState($edtString, $GUI_FOCUS)
While 1
$Response = GUIGetMsg()
Select
    Case $Response = $btnReject
     ExitLoop
    Case $Response = $btnAccept
;    GUICtrlSetData(5, $RetString)
     GUICtrlSetData($EditCtrlId, $RetString)
     ExitLoop
    Case Else
     $RetString = GUICtrlRead($edtString)
EndSelect
WEnd
GUIDelete($winEdit)
EndIf
$DoubleClick = False
EndFunc

Edited May 8, 2013 by jimollerhead

[guinness]

This is how the message should be structured as per the instructions of the help file...

#include <GUIConstantsEx.au3>
#include <WinAPI.au3>
#include <WindowsConstants.au3>

Example()

Func Example()
    Local $hGUI = GUICreate('Left Button Click', 300, 300)

    GUIRegisterMsg($WM_LBUTTONDBLCLK, 'WM_LBUTTONDBLCLK')
    GUISetState(@SW_SHOW, $hGUI)

    While 1
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE
                ExitLoop

        EndSwitch
    WEnd
    GUIDelete($hGUI)
EndFunc   ;==>Example

; http://msdn.microsoft.com/en-us/library/windows/desktop/ms645606(v=vs.85).aspx
Func WM_LBUTTONDBLCLK($hWnd, $iMsg, $wParam, $lParam)
    #forceref $hWnd, $iMsg
    Local $iCode = _WinAPI_LoWord($wParam)
    Local $iX = _WinAPI_LoWord($lParam)
    Local $iY = _WinAPI_HiWord($lParam)
    ConsoleWrite($iCode & ' - Double-Click on GUI:  hWnd = ' & $hWnd & '; X = ' & $iX & '; Y = ' & $iY & @CRLF)
    Return $GUI_RUNDEFMSG
EndFunc   ;==>WM_LBUTTONDBLCLK

I still feel inclined to help and provide a more robust solution, but you seem to have things in hand.

Edited May 8, 2013 by guinness

[kylomas]

jimollerhead,

F.Y.I. - a method of detecting input control double clicks using control subclassing

expandcollapse popup

; *** Start added by AutoIt3Wrapper ***
#include <WindowsConstants.au3>
; *** End added by AutoIt3Wrapper ***

; based on code developed by D4ARKON3 and modified by PhoenixXL

#AutoIt3Wrapper_Add_Constants=n

Local $gui010 = GUICreate('SubClass Two Input Controls', 400, 300)
Local $inp010 = GUICtrlCreateInput('', 10, 20, 380, 20)
Local $inp020 = GUICtrlCreateInput('', 10, 120, 380, 20)
GUISetState()

$hInputSubClassProc = DllCallbackGetPtr(DllCallbackRegister('_InputSubClassProc', 'LRESULT', 'HWND;UINT;WPARAM;LPARAM;UINT_PTR;DWORD_PTR'))
If ($hInputSubClassProc == 0) Then
    MsgBox(16, 'Subclass Test', 'Call to DllCallbackRegister failed.')
    Exit
EndIf

SetWindowSubclass(GUICtrlGetHandle($inp010), $hInputSubClassProc, 0, 0)
If (@error) Then
    MsgBox(16, 'Subclass Test', 'Call to WinProc for inp010 failed.')
    Exit
EndIf

SetWindowSubclass(GUICtrlGetHandle($inp020), $hInputSubClassProc, 1, 0)
If (@error) Then
    MsgBox(16, 'Subclass Test', 'Call to WinProc for inp020 failed.')
    Exit
EndIf

While (True)
    Switch (GUIGetMsg())
        Case -3 ;GUI_EVENT_CLOSE
            ExitLoop
    EndSwitch
WEnd

RemoveWindowSubclass(GUICtrlGetHandle($inp010), $hInputSubClassProc, 0, 0)
RemoveWindowSubclass(GUICtrlGetHandle($inp020), $hInputSubClassProc, 1, 0)

Exit

Func _InputSubClassProc($hWnd, $uMsg, $wParam, $lParam, $uIdSubclass, $dwRefData)
    Switch $uMsg
        Case $wm_lbuttondblclk
            Switch $uIdSubclass
                Case 0
                    GUICtrlSetData($inp010, 'I was double clicked')
                Case 1
                    GUICtrlSetData($inp020, 'I was double clicked')
            EndSwitch
    EndSwitch
    Return DefSubclassProc($hWnd, $uMsg, $wParam, $lParam)
EndFunc   ;==>_InputSubClassProc

Func SetWindowSubclass($hWnd, $pfnSubclass, $uIdSubclass, $dwRefData)
    Local $bResult = DllCall('Comctl32.dll', 'BOOL', 'SetWindowSubclass', _
            'HWND', $hWnd, _
            'ptr', $pfnSubclass, _
            'UINT_PTR', $uIdSubclass, _
            'DWORD_PTR', $dwRefData)
    If (@error) Or ($bResult[0] == 0) Then Return SetError(1, 0, 0)
    Return SetError(0, 0, 1)
EndFunc   ;==>SetWindowSubclass

Func GetWindowSubclass($hWnd, $pfnSubclass, $uIdSubclass, ByRef $dwRefData)
    Local $bResult = DllCall('Comctl32.dll', 'BOOL', 'GetWindowSubclass', _
            'HWND', $hWnd, _
            'ptr', $pfnSubclass, _
            'UINT_PTR', $uIdSubclass, _
            'DWORD_PTR*', 0)
    If (@error) Or ($bResult[0] == 0) Then Return SetError(1, 0, 0)
    $dwRefData = $bResult[4]
    Return SetError(0, 0, 1)
EndFunc   ;==>GetWindowSubclass

Func RemoveWindowSubclass($hWnd, $pfnSubclass, $uIdSubclass, $dwRefData)
    Local $bResult = DllCall('Comctl32.dll', 'BOOL', 'RemoveWindowSubclass', _
            'HWND', $hWnd, _
            'ptr', $pfnSubclass, _
            'UINT_PTR', $uIdSubclass)
    If (@error) Or ($bResult[0] == 0) Then Return SetError(1, 0, 0)
    Return SetError(0, 0, 1)
EndFunc   ;==>RemoveWindowSubclass

Func DefSubclassProc($hWnd, $uMsg, $wParam, $lParam)
    Local $aRet = DllCall('Comctl32.dll', 'LRESULT', 'DefSubclassProc', _
            'HWND', $hWnd, _
            'UINT', $uMsg, _
            'WPARAM', $wParam, _
            'LPARAM', $lParam)
    Return $aRet[0]
EndFunc   ;==>DefSubclassProc

kylomas

[guinness]

That's not for your 'average AutoIt user' and actually you've given me my next topic to grasp. Thanks kylomas.

[kylomas]

D4RKON3 developed the UDF (in examples section), PhoenixXL corrected some errors and provided example.

MSDN has a small intro here.

[guinness]

Thanks. I could see from the comments you were only the messenger 0_-.

[Melba23]

kylomas,

Thank you for posting that - I have been trying (and failing) to detect double-clicks in inputs since this thread started.

M23

[kylomas]

Thanks. I could see from the comments you were only the messenger 0_-.

 

Clarification - D4ARKON developed the UDF.  PhoenixXL corrected a problem with not handing back control correctly.  I wrote this code using an example from the origional topic but expanded it it to show subclassing multiple controls to the same procedure (function).  You can probably tell that from the coding style.

Not to get all anal about it but if there is something wrong with this code then I don't want it to blow back on PhoenixXL or D4RKON3...

edit: spelling

Edited May 11, 2013 by kylomas

[guinness]

You can probably tell that from the coding style.

Your style is unique, that's true. 0_-

[jimollerhead]

Thanks for carrying on with this folks even though I managed a solution (of sorts)

@Guinness, I did indeed spot that example in the helpfile, however knowing the X/Y coordinates at the time of the double-click would give me no end of grief in performing other programming cartwheels in order to figure out which of the many (and dynamically created and destroyed within the app) input fields named 'EditN' the mouse cursor was over.... my main problem in the end was switching from the CLASSNN descriptor to the ID which I had to do by going via the handle.... it would be nice for the double-click to be actually ON the edit field rather than close to it but I am happy with "good enough" rather than "perfect" using the 80/20 rule of programming!! In case you are curious what I am up to, the executable is called Textreme and downloadable from jollybean.co.uk -- I had an enhancement request from a user asking if it would be possible to have a pop-up editor for the functon parameters as some of his search strings were quite long and he'd like to see them in full without having to sideways-scroll the input box. BTW, the current release doesn't yet incorporate the Long String Editor, because the same user asked for a batch run function which is even more work!

@kylomas - Whilst I am sure that your example is a neat and elegant solution, I use AutoIT to *avoid* DLL-hell, not to jump straight in welly-deep! Thank you for contributing though and, even though I am not taking on your solution, you have apparently helped out Melba23 in the process!

[kylomas]

If it works, it works...K.I.S.S.

[guinness]

I'm aware of Textreme, didn't realise you were the developer though.

Believe it or not I used to be anti-UDF, anti-DLL, anti-GUIRegisterMsg, anti-non-Native AutoIt functions but that's the old me.

[jimollerhead]

Well that's one of the most surprising things I have read in the forum -- that someone was "aware" of Textreme!

It's very much just a hobby project that was originally much simpler and for my own use only, that I have expanded the versatility of over time. As I use my own name in here you can now, I guess, make the link from the warp of my initial and surname to the website name!  )   I don't make any efforts to hide the WhoIs info so it would hardly take Clouseau to track down the registered owner! 

Personally, I am not really "anti" anything *provided there is supporting information*. The 3rd and 4th parameters of the GUIRegisterMsg-responding function obviously contain different things depending upon which of the Windows messages you are intercepting. How you all know what these are is a mystery to me as is how you find out about the DLL functions, what they do,  and the parameters they expect/return. There is nowt to be found in the help file (nor would I expect there to be, TBH) so you must have some esoteric info gained from somewhere that I have no knowledge of!

[guinness]

How you all know what these are is a mystery to me as is how you find out about the DLL functions, what they do,  and the parameters they expect/return. There is nowt to be found in the help file (nor would I expect there to be, TBH) so you must have some esoteric info gained from somewhere that I have no knowledge of!

 

By reading MSDN and looking at working examples. The help file explains the function, but the backend stuff is nothing to do with AutoIt. Also considering Microsoft are changing this and that, would mean the help would soon become out dated.

[jimollerhead]

Apologies for not responding to the convo this afternoon Guinness but I was just checking the thread in my lunch-hour so could not engage in a 'live' interaction....I do find your nick a tad ironic given that I am an Englishman marooned in the ROI and I cannot stand the stuff!  [grin].....and not only that I live next door to the original site of the first Guinness brewery!  (which has just been sold BTW)

Edited May 15, 2013 by jimollerhead