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

[sandokanfirst]

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))

GUISetState()

Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE

GUIDelete($hGui)
DllCallbackFree($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
            EndSwitch
    EndSwitch

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

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?

Cheers,

Sando

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 April 23, 2020 by sandokanfirst
clarification

[Nine]

MSDN says : 

Quote

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

 

[sandokanfirst]

Thanks very much, @Nine. I'm amazed that you got to the relevant point in my far too long-winded post!  But this exactly fills the gap in my understanding. I will look into _WinAPI_SetWindowsHookEx.

Cheers,

Sando