Jump to content

trap Windows message $WM_LBUTTONDBLCLK in third party (GUI) program

Recommended Posts

Quick description: I'm building an application for a friend who wants to quit the use of Picasa but is reluctant because of the customised order of his pictures. The only way I know how to retain the custom order is to export all folders (and/or albums) managed by Picasa.

I suppose the quick question is whether the way to trap messages for a window and/or control of your own making (GUI) is fundamentally different from trapping it for windows in a third party GUI. If that makes sense.

My wizard style application has grown steadily but mainly slowly ;) I found out that almost none of the parts of Picasa are recognisable Windows controls. (according to Au3Info and several other detection tools I've tried) So far, I've managed to work around that by reading and writing values to the registry w/ regard to export size, export location and quality.

However. the final step appears to be the most difficult for me. What I tried to do is for the user to indicate two folders by double clicking on them. (Those two folders represent the range of folders that have to be exported). On this forum I found a contribution by Rasim to subclass a Window and replace the Windows procedure by a new one; see https://www.autoitscript.com/forum/topic/76841-detect-double-click-on-edit-box/ Here is his code to detect a double click in an edit control:

$hGUI = GUICreate("Test GUI", 300, 200)

$edit = GUICtrlCreateEdit("", 10, 10, 280, 180)

$wProcHandle = DllCallbackRegister("_WindowProc", "ptr", "hwnd;uint;wparam;lparam")

$wProcOld = _WinAPI_SetWindowLong(GUICtrlGetHandle($edit), $GWL_WNDPROC, DllCallbackGetPtr($wProcHandle))




Func _WindowProc($hWnd, $Msg, $wParam, $lParam)
    Switch $hWnd
        Case GUICtrlGetHandle($edit)
            Switch $Msg
                Case $WM_LBUTTONDBLCLK
                    ConsoleWrite("-> Left mouse double click" & @LF)
                    Return 0

    Local $aRet = DllCall("user32.dll", "int", "CallWindowProc", "ptr", $wProcOld, _
                          "hwnd", $hWnd, "uint", $Msg, "wparam", $wParam, "lparam", $lParam)
    Return $aRet[0]

The(/a) fundamental difference between this code and my program is that I try to do the same with Picasa and that that is not a GUI created in AutoIt. So instead of GUICtrlGetHandle($edit), I call the above function with the Picasa window handle. However, it doesn't work. Neither does Notepad if I pass its handle. I'm sure I express myself rather clumsily, but is it imperative to create and address your own GUI if you want to detect a double click in a third party program? Why wouldn't the above code work when automating a non AutoIt GUI?



PS (Edit): I'm sure there are smarter ways to achieve what I want in Picasa, but I'm also really interested in AutoIts working. I was a Delphi developer in the past, and although i see quite a few similarities, especially between Koda and the IDE, I've also come to realise how much we Delphi developers have been shielded from the intricacies of Windows and its frameworks. I find AutoIt fascinating, and incredibly useful.

Edited by sandokanfirst
Link to comment
Share on other sites

MSDN says


Calling SetWindowLongPtr with the GWLP_WNDPROC index creates a subclass of the window class used to create the window. An application can subclass a system class, but should not subclass a window class created by another process.

In order to do something similar you could use _WinAPI_SetWindowsHookEx instead


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...