GUIRegisterMsg20 - Subclassing Made Easy

[LarsJ]

GUIRegisterMsg() subclasses an AutoIt GUI. Ie. a window created with GuiCreate(). A few issues are related to GUIRegisterMsg():

• It cannot subclass a control
• Some messages cannot be handled
• Only one function for a specific message

These issues cannot be described as errors. They are probably consequences of a design choice to limit the complexity of the function.

A few issues are related to the subclassing technique in general:

• _WinAPI_SetWindowLong()
• The Subclassing bug

GUIRegisterMsg20() addresses all these issues.

2020-02-23: It's probably not true that GUIRegisterMsg() is based on the subclassing technique. The messages handled by GUIRegisterMsg() are more likely to originate from the message loop in the window procedure (implemented in internal code) of the main GUI window.

 

What is subclassing?
Subclassing is a technique to get information from standard controls through Windows messages, and to modify the functionality of standard controls by responding to these messages. Eg. to change the background color of listview cells.

 

GUIRegisterMsg20
GUIRegisterMsg20.au3 is a small UDF implemented in 100 code lines. This is the documentation for GUIRegisterMsg20():

; Register a message handler function for a window or control message
; GUIRegisterMsg20( $vWinOrCtrl, _ ; Window handle or control ID/handle
;                   $WM_MESSAGE, _ ; Window message or control message
;                   $hFunction )   ; User supplied message handler func
;
; $vWinOrCtrl  GUI handle as returned by GUICreate, controlID as returned by GUICtrlCreate<Control> functions
;              or control handle as returned by _GUICtrl<Control>_Create UDF functions or GUICtrlGetHandle.
;
; $WM_MESSAGE  A Windows message code as listed in Appendix section in help file. Or a control message code
;              eg. a LVM_MESSAGE or TVM_MESSAGE as listed in ListViewConstants.au3 or TreeViewConstants.au3.
;              This parameter is only checked to be within the valid range of Windows and control messages:
;              0x0000 - 0x7FFF.
;
; $hFunction   The user supplied function (not the name but the FUNCTION) to call when the message appears.
;              The function is defined in exactly the same way as the function for the official GUIRegisterMsg:
;              Takes four input parameters ($hWnd, $iMsg, $wParam, $lParam) and returns $GUI_RUNDEFMSG to conti-
;              nue with default message handling, or a specific value if the message is handled by the function.
;
; Error code in @error                                               Return value
;     1 => Invalid window handle or control ID/handle                    Success => 1
;     2 => Invalid Window or control message                             Failure => 0
;     3 => Invalid function handle
;     4 => Too many subclasses

 

And this is the very central internal function that is called directly from the code in ComCtl32.dll:

Func GUIRegisterMsg20_Handler( $hWnd, $iMsg, $wParam, $lParam, $idx, $pData )
  If $iMsg <> $aGUIRegisterMsg20[$idx][3] Then Return DllCall( "comctl32.dll", "lresult", "DefSubclassProc", "hwnd", $hWnd, "uint", $iMsg, "wparam", $wParam, "lparam", $lParam )[0]
  Local $vRetVal = $aGUIRegisterMsg20[$idx][4]( $hWnd, $iMsg, $wParam, $lParam ) ; Execute user supplied message handler function
  If $vRetVal == "GUI_RUNDEFMSG" Then Return DllCall( "comctl32.dll", "lresult", "DefSubclassProc", "hwnd", $hWnd, "uint", $iMsg, "wparam", $wParam, "lparam", $lParam )[0]
  Return $vRetVal
  #forceref $pData
EndFunc

 

It's rarely necessary to call GUIUnRegisterMsg20(). Message handlers are unregistered when the program exits. An exception is a situation where message handles are registered and unregistered on the fly, eg. due to user actions.

 

Message monitor
When it comes to topics like subclassing, a message monitor is required eg. Windows Message Monitor.

 

ListView example
Listview example is a custom drawn listview with colored cells. If we focus on subclass implementation, this is the difference between GUIRegisterMsg() and GUIRegisterMsg20() code.

GUIRegisterMsg():

; ...
GUIRegisterMsg( $WM_NOTIFY, "WM_NOTIFY" )
; ...

 

GUIRegisterMsg20():

#include "..\..\Includes\GUIRegisterMsg20.au3"
; ...
GUIRegisterMsg20( $hGui, $WM_NOTIFY, WM_NOTIFY )
; ...

GUIRegisterMsg20() takes $hGui as first parameter. The message handler function in third parameter is a function variable. Not a string.

The message handler function, WM_NOTIFY, is exactly the same in the two examples.

If you run the scripts that contains message monitor code, you will notice a remarkable difference between the two scripts. In the GUIRegisterMsg20() script, there are no NM_CUSTOMDRAW notifications in the monitor. What's the reason?

 

All GUIRegisterMsg() examples in help file that looks like this:

; ...
GUIRegisterMsg( $WM_MESSAGE, "WM_MESSAGE" )
; ...

 

Can be implemented with GUIRegisterMsg20() this way:

; ...
GUIRegisterMsg20( $hGui, $WM_MESSAGE, WM_MESSAGE )
; ...

 

Input example
Input example is based on this forum thread. Run Input.au3 to see the issues: You can paste a number into the control, a context menu shows up on right click, and a tooltip is displayed if you press a letter.

Let's see what's going on with the message monitor. When you solve issues with a message monitor, you are generally interested in finding a particular message or a pattern of a few messages. If there are multiple instances of the message or pattern, it's easier to find. The action that generates the message or pattern should be repeated 3 - 4 times.

Run "Input, wmm.au3", paste a number into the control 3 - 4 times eg. 18 (result = 18181818), right click 3 - 4 times, press a letter 3 - 4 times. Press Esc to delete Input GUI and start WMM GUI. Scroll down until you see tomato red messages. You'll see the messages WM_PASTE, WM_CONTEXTMENU and EM_SHOWBALLOONTIP.

Note that all three messages are received by the Input control. This means that GUIRegisterMsg() cannot be used. It can only handle messages received by the GUI.

Because all messages are received by the Input control you can register three message handlers this way in "Input, subclass.au3":

; Subclass Input
GUIRegisterMsg20( $idInput, $WM_PASTE, WM_PASTE )
GUIRegisterMsg20( $idInput, $WM_CONTEXTMENU, WM_CONTEXTMENU )
GUIRegisterMsg20( $idInput, $EM_SHOWBALLOONTIP, EM_SHOWBALLOONTIP )

 

To implement message handler functions you have to read Microsoft documentation. Only for EM_SHOWBALLOONTIP it's completely clear that the message is suppressed by returning False or 0. For all three messages, however, you must return 0 to suppress the message:

; WM_PASTE message handler function
Func WM_PASTE( $hWnd, $iMsg, $wParam, $lParam )
  Return 0
  #forceref $hWnd, $iMsg, $wParam, $lParam
EndFunc

; WM_CONTEXTMENU message handler function
Func WM_CONTEXTMENU( $hWnd, $iMsg, $wParam, $lParam )
  Return 0
  #forceref $hWnd, $iMsg, $wParam, $lParam
EndFunc

; EM_SHOWBALLOONTIP message handler function
Func EM_SHOWBALLOONTIP( $hWnd, $iMsg, $wParam, $lParam )
  Return 0
  #forceref $hWnd, $iMsg, $wParam, $lParam
EndFunc

 

As all three functions are the same, the code can be reduced a little bit in "Input, final.au3":

expandcollapse popup

; GUICtrlCreateInput - Disable copy/ paste, right click menu and balloon pop-up
; https://www.autoitscript.com/forum/index.php?showtopic=179052

#include <GuiEdit.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include "..\..\Includes\GUIRegisterMsg20.au3"

Opt( "MustDeclareVars", 1 )

Example()

Func Example()
  ; Create GUI
  GUICreate( "Input (numbers only)", 300, 118 )

  ; Create Input
  Local $idInput = GUICtrlCreateInput( "", 50, 50, 200, 18, $GUI_SS_DEFAULT_INPUT+$ES_NUMBER )

  ; Create Label
  GUICtrlCreateLabel( "No paste, no context menu, no balloontip", 50, 70, 200, 18 )

  ; Subclass Input
  GUIRegisterMsg20( $idInput, $WM_PASTE, InputFunc )
  GUIRegisterMsg20( $idInput, $WM_CONTEXTMENU, InputFunc )
  GUIRegisterMsg20( $idInput, $EM_SHOWBALLOONTIP, InputFunc )

  ; Show GUI
  GUISetState()

  ; Msg loop
  While 1
    Switch GUIGetMsg()
      Case $GUI_EVENT_CLOSE
        ExitLoop
    EndSwitch
  WEnd

  ; Cleanup
  GUIDelete()
EndFunc

; Input message handler function
Func InputFunc( $hWnd, $iMsg, $wParam, $lParam )
  Return 0
  #forceref $hWnd, $iMsg, $wParam, $lParam
EndFunc

Just by looking at the code (including UDF in top, registering and implementing message handlers in middle and bottom) it seems not to be that hard.

 

Header example
The width of listview columns can be changed by dragging header item separators with the mouse. If you want to disable this feature you have to suppress HDN_BEGINTRACK notifications from the header control. They are contained in WM_NOTIFY messages. And you have to suppress WM_SETCURSOR messages when the mouse cursor hover over header item separators. This prevents a cursor shape indicating that separators can be dragged.

Run "ListView header, wmm.au3". Drag the header item separators forth and back. This generates a huge number of messages. Press Esc to delete GUI and start WMM GUI. Scroll down until you see tomato red messages.

Note that HDN_BEGINTRACK notifications in WM_NOTIFY messages are sent first to the listview and then to the GUI. They can be catched by GUIRegisterMsg(). Here they'll be catched by GUIRegisterMsg20() from the listview. WM_SETCURSOR messages must be catched from the header:

; Subclass ListView and Header
GUIRegisterMsg20( $idListView, $WM_NOTIFY, ListViewFunc )
GUIRegisterMsg20( $hHeader, $WM_SETCURSOR, HeaderFunc )

 

Handler functions:

; ListView message handler function
Func ListViewFunc( $hWnd, $iMsg, $wParam, $lParam )
  If $HDN_BEGINTRACKW = DllStructGetData( DllStructCreate( $tagNMHEADER, $lParam ), "Code" ) Then Return 1
  Return $GUI_RUNDEFMSG
  #forceref $hWnd, $iMsg, $wParam
EndFunc

; Header message handler function
Func HeaderFunc( $hWnd, $iMsg, $wParam, $lParam )
  Return 1
  #forceref $hWnd, $iMsg, $wParam, $lParam
EndFunc

Again, just by looking at the code (including UDF in top, registering and implementing message handlers in middle and bottom) it seems not to be that hard.

2020-02-23: Note that if you want to prevent the width of the listview columns from being changed you can simply add the HDS_NOSIZING style to the header control. I wasn't aware of that when I made the example.

 

TreeView example (2018-08-15)
TreeView example is based on this forum thread. Run TreeView.au3 (copied from first post in thread) to see the issue: No WM_COMMAND messages are received on right click in treeview.

"TreeView, wmm.au3" shows the problem: WM_COMMAND messages generated on right clicks are sent to the treeview and not the main GUI. This means that GUIRegisterMsg() isn't able to catch the messages.

To solve the problem include GUIRegisterMsg20.au3 in top of script and use GUIRegisterMsg20() to subclass the treeview as it's done in "TreeView, subclass.au3":

;...
#include "..\..\Includes\GUIRegisterMsg20.au3"
;...
GUIRegisterMsg20( $g_hTreeView, $WM_COMMAND, WM_COMMAND )

The existing WM_COMMAND() message handler is reused.

That was two code lines to solve the problem. It can hardly be easier.

 

Too much code (2018-09-30)
A custom drawn listview generates a lot of WM_NOTIFY messages. If custom draw code is used to draw selected items with GDI-functions in the post paint drawing stage, much code will be executed to respond to all these messages. If it's also a virtual listview, it'll double the number of messages (Examples\5) Too much code\ListView.au3):

expandcollapse popup

Func WM_NOTIFY( $hWnd, $iMsg, $wParam, $lParam )
  Local Static $tText = DllStructCreate( "wchar[100]" ), $pText = DllStructGetPtr( $tText )
  Local Static $tRect = DllStructCreate( $tagRECT ), $pRect = DllStructGetPtr( $tRect )

  Switch DllStructGetData( DllStructCreate( $tagNMHDR, $lParam ), "Code" )
    Case $LVN_GETDISPINFOW
      ; Fill virtual listview
      Local $tNMLVDISPINFO = DllStructCreate( $tagNMLVDISPINFO, $lParam )
      If Not BitAND( DllStructGetData( $tNMLVDISPINFO, "Mask" ), $LVIF_TEXT ) Then Return
      Local $sItem = $aItems[DllStructGetData($tNMLVDISPINFO,"Item")][DllStructGetData($tNMLVDISPINFO,"SubItem")]
      DllStructSetData( $tText, 1, $sItem )
      DllStructSetData( $tNMLVDISPINFO, "TextMax", StringLen( $sItem ) )
      DllStructSetData( $tNMLVDISPINFO, "Text", $pText )
      Return

    Case $NM_CUSTOMDRAW
      ; Draw back colors
      Local $tNMLVCUSTOMDRAW = DllStructCreate( $tagNMLVCUSTOMDRAW, $lParam )
      Local $dwDrawStage = DllStructGetData( $tNMLVCUSTOMDRAW, "dwDrawStage" ), $iItem
      Switch $dwDrawStage                        ; Holds a value that specifies the drawing stage
        Case $CDDS_PREPAINT                      ; Before the paint cycle begins
          Return $CDRF_NOTIFYITEMDRAW            ; Notify the parent window of any item-related drawing operations
        Case $CDDS_ITEMPREPAINT                  ; Before painting an item
          Return $CDRF_NOTIFYSUBITEMDRAW         ; Notify the parent window of any subitem-related drawing operations
        Case $CDDS_ITEMPREPAINT + $CDDS_SUBITEM  ; Before painting a subitem
          $iItem = DllStructGetData( $tNMLVCUSTOMDRAW, "dwItemSpec" )
          If GUICtrlSendMsg( $idListView, $LVM_GETITEMSTATE, $iItem, $LVIS_SELECTED ) Then Return $CDRF_NOTIFYPOSTPAINT      ; Selected item
          DllStructSetData( $tNMLVCUSTOMDRAW, "ClrTextBk", $aColors[$iItem][DllStructGetData($tNMLVCUSTOMDRAW,"iSubItem")] ) ; Normal item
          Return $CDRF_NEWFONT                   ; $CDRF_NEWFONT must be returned after changing font or colors
        Case $CDDS_ITEMPOSTPAINT + $CDDS_SUBITEM ; After painting a subitem
          Local $hDC = DllStructGetData( $tNMLVCUSTOMDRAW, "hdc" )
          ; Subitem rectangle
          $iItem = DllStructGetData( $tNMLVCUSTOMDRAW, "dwItemSpec" )
          Local $iSubItem = DllStructGetData( $tNMLVCUSTOMDRAW, "iSubItem" )
          DllStructSetData( $tRect, "Left", $LVIR_LABEL )
          DllStructSetData( $tRect, "Top", $iSubItem )
          GUICtrlSendMsg( $idListView, $LVM_GETSUBITEMRECT, $iItem, $pRect )
          DllStructSetData( $tRect, "Left",   DllStructGetData( $tRect, "Left"   ) + 2 )
          DllStructSetData( $tRect, "Top",    DllStructGetData( $tRect, "Top"    ) + 1 )
          DllStructSetData( $tRect, "Right",  DllStructGetData( $tRect, "Right"  ) - 2 )
          DllStructSetData( $tRect, "Bottom", DllStructGetData( $tRect, "Bottom" ) - 1 )
          ; Subitem back color
          Local $hBrush = DllCall( "gdi32.dll", "handle", "CreateSolidBrush", "int", $aColors[$iItem][$iSubItem] )[0] ; _WinAPI_CreateSolidBrush
          DllCall( "user32.dll", "int", "FillRect", "handle", $hDC, "struct*", $tRect, "handle", $hBrush ) ; _WinAPI_FillRect
          DllCall( "gdi32.dll", "bool", "DeleteObject", "handle", $hBrush ) ; _WinAPI_DeleteObject
          ; Draw subitem text
          DllStructSetData( $tRect, "Top", DllStructGetData( $tRect, "Top" ) + 1 )
          DllCall( "gdi32.dll", "int", "SetTextColor", "handle", $hDC, "int", 0 ) ; _WinAPI_SetTextColor
          DllCall( "gdi32.dll", "int", "SetBkMode", "handle", $hDC, "int", $TRANSPARENT ) ; _WinAPI_SetBkMode
          DllCall( "user32.dll", "int", "DrawTextW", "handle", $hDC, "wstr", $aItems[$iItem][$iSubItem], "int", -1, "struct*", $tRect, "uint", $DT_CENTER ) ; _WinAPI_DrawText
          Return $CDRF_NEWFONT                   ; $CDRF_NEWFONT must be returned after changing font or colors
      EndSwitch
  EndSwitch

  Return $GUI_RUNDEFMSG
  #forceref $hWnd, $iMsg, $wParam
EndFunc

If there are a lot of messages and some messages perform quite a lot of code, you can end up in a situation where more code is performed than there's time for. The result is that the WM_NOTIFY messages are blocked and the code fails:

You can provoke the error this way: Click a row in the listview (not one of the very top rows). Press Shift+Down arrow to select multiple rows. The problem will arise after just a few rows. Press Ctrl+Break in SciTE to stop the code.

2020-02-23: The only solution to the problem is probably to implement the WM_NOTIFY() function in compiled code as demonstrated here.

 

Message flow (update 2018-09-30)
In these examples, the message flow is examined with left and right mouse clicks. Several message handles are implemented. A standard AutoIt message loop (MessageLoop Mode) where messages are received with GUIGetMsg(). A message handler based on GUIRegisterMsg(). And a message handler created with GUIRegisterMsg20(). In addition, there is the internal AutoIt message handler (C++ code). The purpose is to determine in which order a message is received by all these different message handlers.

Script 1) implements the three message handlers. By examining the message flow with the monitor we can see that the messages are received in this order:

Script 2) implements an additional GUIRegisterMsg20() message handler for the same mouse click messages but with another message handler function. It seems that the last created GUIRegisterMsg20() handler, is the first to receive the mouse clicks.

In script 3) mouse clicks are performed in an Edit control instead of an empty GUI. The GUIRegisterMsg() message handler does not receive the mouse clicks.

At what point in the flow chart does the message monitor hook into the message flow? Since message detection is implemented through subclassing it hooks into the message flow just before the internal AutoIt message handler.

Now we can answer the question from the listview example above: Why do we not see any NM_CUSTOMDRAW notifications in the message monitor from the GUIRegisterMsg20() script. Because these notifications are all answered with one of the custom draw return values and not $GUI_RUNDEFMSG. The custom draw return values goes directly back to the operating system and the messages are no longer forwarded in the message chain. The message flow stops already at the GUIRegisterMsg20() message handler function and never reaches the internal AutoIt message handler. Therefore, the messages do not reach the monitor either.

 

The issues
The listview example at the top shows that GUIRegisterMsg20() is very similar to GUIRegisterMsg(). You can do the same things with GUIRegisterMsg20() as you can do with GUIRegisterMsg(). This means that you can use GUIRegisterMsg20() in a UDF, while the user can use GUIRegisterMsg() in his own code exactly as described in the help file. From the flow chart above you know that the GUIRegisterMsg20() message handler function will receive messages before the GUIRegisterMsg() message handler function.

Let's review the issues mentioned in beginning of post. Only GUIRegisterMsg20() can subclass a control and receive control messages. This is demonstrated in the input example.

The mouse clicks in the edit control discussed above shows that GUIRegisterMsg() isn't receiving all WM_MESSAGEs and therefore cannot handle these messages.

The mouse clicks in the section above also shows that GUIRegisterMsg20() can use several functions for the same message.

Because GUIRegisterMsg20() uses SetWindowSubclass to implement subclassing, problems related to _WinAPI_SetWindowLong() are avoided.

Because GUIRegisterMsg20() returns directly from the DefSubclassProc DllCall, the subclassing bug never comes into play.

 

Conclusion
GUIRegisterMsg20 UDF takes care of the tedious and cumbersome task of configuring subclassing. Ie. to set up SetWindowSubclass, DefSubclassProc and RemoveWindowSubclass functions. It uses a message handler function that is very similar to the function used in the official GUIRegisterMsg(). You can concentrate on analyzing the message flow and code the message handler function.

 

7z-file
You need AutoIt 3.3.12 or later. Tested on Windows 7 and Windows 10.

Note that the contents of the Includes folder in the Windows Message Monitor 7z-file must be installed in the WMMincl directory to use Windows Message Monitor.

Comments are welcome. Let me know if there are any issues.

GUIRegisterMsg20.7z

Edited February 23, 2020 by LarsJ
A few updates, new 7z-file

[mLipok]

Looking interesting (as always for all project from you).
I will analyze this later after my vacation.

Thanks.

 

[LarsJ]

You are very fast.

[mLipok]

I was just reading your  Windows Message Monitor and then I check whats new on the forum, so I jump to this thread,  quick look, thinking, posting 

[LarsJ]

Added new treeview example. See first post.

Minor WMM updates. See WMM thread.

Updated zip-file in bottom of first post.

[kcvinu]

@LarsJ ,

I have been busy due to some job related reasons and hence, I didn’t do any programming for some time. Have seen your post in a this forum. Thank you for this UDF. I was using the SetWindowSubclass for such requirements, because the GUIRegMsg had some shortcomings which you mentioned in this post. I will sure leave a comment after testing your UDF.

[kcvinu]

@LarsJ,

WinMsgMon is really Powerful. Thank you for this script. In fact I've had a need for such a script. I often use the program named Control Spy to find out which messages are coming to a control. Messages and notification codes of All common Windows controls, will be displayed in that program. But there is no number for that messages. Lot of messages appear in a list box within a second. We do not know which is the first one or the last one. But your WinMsgMon has filled that shortcoming. I like it. Thanks.

 

[kcvinu]

@LarsJ ,

Checked GUIRegisterMsg20() just now. Fantastic !. With this function, AutoIt is now become somewhat like an event driven programming language. Really ! Please tell me what is the reason behind this name "GUIRegisterMsg20(). If i were you, then i will name it something like "RegisterMsgEx".

 

[LarsJ]

The name should be interpreted as GUIRegisterMsg() version 2.0. The purpose of GUIRegisterMsg20() is the same as GUIRegisterMsg(). It's used for the same thing, it's used in the same way, and the message handler function is the same. The version 2.0 hint shows that the function can do a little bit more than the original function: It can subclass a control and not just a GUI window.

[spudw2k]

Cool stuff LarsJ.  

On 8/17/2018 at 12:48 AM, LarsJ said:

The purpose of GUIRegisterMsg20() is the same as GUIRegisterMsg().

The version 2.0 hint shows that the function can do a little bit more than the original function...

doesn't RegisterMsgEx() do this as well, as kcvinu suggested? 

[LarsJ]

Yes, both names can be used and then we can just as well keep the current name.

[LarsJ]

Added new example that shows how to end up performing too much code.

"Message flow" section is updated.

New zip-file in bottom of first post.

[LarsJ]

A few updates and new 7z-file at bottom of first post.

[MrCreatoR]

Hi,

I am trying to use this to subclass the SHBrowseForFolderW (add checkboxes, and other stuff).

 

expandcollapse popup

#include <TreeViewConstants.au3>
#include <WindowsConstants.au3>
#include <WinAPIDlg.au3>
#include <GUIRegisterMsg20.au3>

$sInitDir = @ProgramFilesDir
$sRoot = _WinAPI_PathStripToRoot($sInitDir)

Global $hTV

$hBrowseProc = DllCallbackRegister('_BrowseProc', 'int', 'hwnd;uint;lparam;ptr')
$pBrowseProc = DllCallbackGetPtr($hBrowseProc)

$pText = _WinAPI_CreateString($sInitDir)
$sPath = _WinAPI_BrowseForFolderDlg($sRoot, 'Select a folder from the list below.', BitOR($BIF_RETURNONLYFSDIRS, $BIF_BROWSEINCLUDEFILES, $BIF_VALIDATE, $BIF_USENEWUI), $pBrowseProc, $pText)
_WinAPI_FreeMemory($pText)

If $sPath Then
    ConsoleWrite('--------------------------------------------------' & @CRLF)
    ConsoleWrite($sPath & @CRLF)
EndIf

DllCallbackFree($hBrowseProc)

Func _BrowseProc($hWnd, $iMsg, $wParam, $lParam)
    Local $sPath
    
    Switch $iMsg
        Case $BFFM_INITIALIZED
            $hTV = ControlGetHandle($hWnd, '', 'SysTreeView321')
            
            _WinAPI_SetWindowLong($hTV, $GWL_STYLE, BitOR(_WinAPI_GetWindowLong($hTV, $GWL_STYLE), $TVS_CHECKBOXES))
            _WinAPI_SetWindowText($hWnd, 'MyTitle')
            _SendMessage($hWnd, $BFFM_SETSELECTIONW, 1, $lParam)
            
            ;GUIRegisterMsg($WM_NOTIFY, 'WM_NOTIFY')
            GUIRegisterMsg20($hTV, $WM_NOTIFY, WM_NOTIFY)
        Case $BFFM_SELCHANGED
            $sPath = _WinAPI_ShellGetPathFromIDList($wParam)
            
            If Not @error Then
                ConsoleWrite($sPath & @CRLF)
            EndIf
    EndSwitch
    
    Return 0
EndFunc   ;==>_BrowseProc

Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam)
    #forceref $hWnd, $iMsg, $lParam
    Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR
    
    $tNMHDR = DllStructCreate($tagNMHDR, $lParam)
    $hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
    $iIDFrom = DllStructGetData($tNMHDR, "IDFrom")
    $iCode = DllStructGetData($tNMHDR, "Code")
    
    Switch $hWndFrom
        Case $hTV
            Switch $iCode
                Case $NM_CLICK ; The user has clicked the left mouse button within the control
                    ConsoleWrite('Clicked' & @CRLF)
                    ; Return 1 ; nonzero to not allow the default processing
                    Return 0 ; zero to allow the default processing
                Case Else
                    ConsoleWrite(1 & @CRLF)
            EndSwitch
    EndSwitch
    
    Return 'GUI_RUNDEFMSG'
EndFunc

But no success, any ideas?

[LarsJ]

You should only use SHBrowseForFolderW if you're on Windows XP. Otherwise, you should use New style FileSelectFolder.

[MrCreatoR]

Why? it's working fine on my Win10.

18 minutes ago, LarsJ said:

you should use New style FileSelectFolder.

It seems that it's much more complicated to do what i want with this method.

The question is why the subclassing does not work with BrowseForFolderDlg?

[LarsJ]

Because WM_NOTIFY messages are sent to the parent window. So use

GUIRegisterMsg20(_WinAPI_GetParent($hTV), $WM_NOTIFY, WM_NOTIFY)

 

[MrCreatoR]

1 hour ago, LarsJ said:

Because WM_NOTIFY messages are sent to the parent window. So use

Thanks, now it works!

Strange, but i though that $hWnd passed to _BrowseProc it's the parent, apparently not.

[LarsJ]

UI Automation code can reveal the structure of the controls in the window:

expandcollapse popup

#AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7

#AutoIt3Wrapper_UseX64=y

Opt( "MustDeclareVars", 1 )

#include "UIA_Constants.au3"

; Array index offset relative to UIA_ControlTypeIds = -50000
Global Const $aUIControls = [ _
  "Button",       "Calendar",     "CheckBox",     "ComboBox",     "Edit",         "Hyperlink",    "Image",        "ListItem",     "List", _
  "Menu",         "MenuBar",      "MenuItem",     "ProgressBar",  "RadioButton",  "ScrollBar",    "Slider",       "Spinner",      "StatusBar", _
  "Tab",          "TabItem",      "Text",         "ToolBar",      "ToolTip",      "Tree",         "TreeItem",     "Custom",       "Group", _
  "Thumb",        "DataGrid",     "DataItem",     "Document",     "SplitButton",  "Window",       "Pane",         "Header",       "HeaderItem", _
  "Table",        "TitleBar",     "Separator",    "SemanticZoom", "AppBar" ]

Global $oUIAutomation

Example()

Func Example()
  ; Create UI Automation object
  $oUIAutomation = ObjCreateInterface( $sCLSID_CUIAutomation, $sIID_IUIAutomation, $dtag_IUIAutomation )
  If Not IsObj( $oUIAutomation ) Then Return ConsoleWrite( "$oUIAutomation ERR" & @CRLF )
  ConsoleWrite( "$oUIAutomation OK" & @CRLF )

  ; Get Desktop element
  Local $pDesktop, $oDesktop
  $oUIAutomation.GetRootElement( $pDesktop )
  $oDesktop = ObjCreateInterface( $pDesktop, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement )
  If Not IsObj( $oDesktop ) Then Return ConsoleWrite( "$oDesktop ERR" & @CRLF )
  ConsoleWrite( "$oDesktop OK" & @CRLF )

  Local $pCondition0, $pCondition1, $pAndCondition1
  $oUIAutomation.CreatePropertyCondition( $UIA_ClassNamePropertyId, "#32770", $pCondition0 )
  $oUIAutomation.CreatePropertyCondition( $UIA_NamePropertyId, "MyTitle", $pCondition1 )
  $oUIAutomation.CreateAndCondition( $pCondition0, $pCondition1, $pAndCondition1 )
  If Not $pAndCondition1 Then Return ConsoleWrite( "$pAndCondition1 ERR" & @CRLF )
  ConsoleWrite( "$pAndCondition1 OK" & @CRLF )

  Local $pWindow1, $oWindow1
  $oDesktop.FindFirst( $TreeScope_Children, $pAndCondition1, $pWindow1 )
  $oWindow1 = ObjCreateInterface( $pWindow1, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement )
  If Not IsObj( $oWindow1 ) Then Return ConsoleWrite( "$oWindow1 ERR" & @CRLF )
  ConsoleWrite( "$oWindow1 OK" & @CRLF & @CRLF )

  ; List all automation elements of a window
  ; in a hierarchical structure like a treeview.
  Local $iControl, $sElement
  $oWindow1.GetCurrentPropertyValue( $UIA_ControlTypePropertyId, $iControl )
  $oWindow1.GetCurrentPropertyValue( $UIA_NamePropertyId, $sElement )
  ConsoleWrite( $aUIControls[$iControl-50000] & ( $sElement ? ": " & $sElement : "" ) & @CRLF )
  ListDescendants( $oWindow1 )
  ;ListDescendants( $oWindow1, 2 ) ; Only two levels
EndFunc

; List all child elements of parent
Func ListDescendants( $oParent, $iLevels = 0, $iLevel = 0 )
  If Not IsObj( $oParent ) Then Return
  If $iLevels And $iLevel = $iLevels Then Return

  ; Create RawViewWalker object
  Local $pRawViewWalker, $oRawViewWalker
  $oUIAutomation.RawViewWalker( $pRawViewWalker )
  $oRawViewWalker = ObjCreateInterface( $pRawViewWalker, $sIID_IUIAutomationTreeWalker, $dtag_IUIAutomationTreeWalker )
  If Not IsObj( $oRawViewWalker ) Then Return ConsoleWrite( "$oRawViewWalker ERR" & @CRLF )

  ; Get first child element
  Local $pUIElement, $oUIElement
  $oRawViewWalker.GetFirstChildElement( $oParent, $pUIElement )
  $oUIElement = ObjCreateInterface( $pUIElement, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement )

  Local $sIndent = ""
  For $i = 0 To $iLevel
    $sIndent &= "    "
  Next

  Local $iControl, $sElement
  While IsObj( $oUIElement )
    $oUIElement.GetCurrentPropertyValue( $UIA_ControlTypePropertyId, $iControl )
    $oUIElement.GetCurrentPropertyValue( $UIA_NamePropertyId, $sElement )
    ConsoleWrite( $sIndent & $aUIControls[$iControl-50000] & ( $sElement ? ": " & $sElement : "" ) & @CRLF )

    ListDescendants( $oUIElement, $iLevels, $iLevel + 1 )

    $oRawViewWalker.GetNextSiblingElement( $oUIElement, $pUIElement )
    $oUIElement = ObjCreateInterface( $pUIElement, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement )
  WEnd
EndFunc

expandcollapse popup

$oUIAutomation OK
$oDesktop OK
$pAndCondition1 OK
$oWindow1 OK

Window: MyTitle
    Text: Select a folder from the list below.
    Pane: Select a folder from the list below.
        Tree: Select a folder from the list below.
            ScrollBar: Vertical
                Button: Line up
                Thumb: Position
                Button: Page down
                Button: Line down
            TreeItem: System (C:)
                TreeItem: $Recycle.Bin
                TreeItem: Documents and Settings
                TreeItem: Intel
                TreeItem: MSOCache
                TreeItem: PerfLogs
                TreeItem: Program Files
                TreeItem: Program Files (x86)
                TreeItem: ProgramData
                TreeItem: Recovery
                TreeItem: System
                TreeItem: System Volume Information
                TreeItem: Users
                TreeItem: Windows
                TreeItem: hiberfil.sys
                TreeItem: Install.log
                TreeItem: pagefile.sys
                TreeItem: SYSTAG.BIN
    Text: Folder:
    Edit: Folder:
    Button: Make New Folder
    Button: OK
    Button: Cancel
    Thumb
    TitleBar
        Button: Close

The control, which in UI Automation code is registered as a pane control, is the parent of the tree view.

The code is copied from this post but is slightly updated to show the top window as the first level.

UIA_Constants.au3 can be copied from UI Automation UDFs.

Edited April 16, 2020 by LarsJ

[Bilgus]

Couple Questions 

First

Why is it limited to windows messages 0- WM_USER (32767)

is that a design decision or a hard limit?

Second

have you done any performance testing to see how much extra overhead (if any) with filtering the message loop in AutoIt script versus versus the interpreter?