Leaderboard

ahhh, cheap labor !

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": ; 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): 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

just a simple festive decoration for our screen Happy holidays to all! p.s. to turn it off just click on any "light" and then press esc #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <Constants.au3> #include <GuiListView.au3> #include <GuiImageList.au3> Global $aColors = StringSplit("0x000000,0x0000AA,0x00AA00,0x00AAAA,0xAA0000,0xAA00AA,0xAAAA00,0xAAAAAA,0x555555,0x0000FF,0x00FF00,0x00FFFF,0xFF0000,0xFF00FF,0xFFFF00,0xFFFFFF", ',', 2) Global $iColors = UBound($aColors) - 1 Global $iX = @DesktopWidth, $iY = @DesktopHeight Global $iNrX = Int($iX/17), $iNrY = Int($iY/17) - 2 Global $hGui1 = GUICreate("", $iX, 17, 0, 0, $WS_POPUPWINDOW, $WS_EX_TOPMOST) ; top bar Global $idListview1 = GUICtrlCreateListView("", 0, 0, $iX, 17) GUICtrlSetStyle($idListview1, BitOR($LVS_ICON, $LVS_NOSCROLL)) GUISetState() Global $hGui2 = GUICreate("", 17, $iY - 17 - 17 , 0, 17, $WS_POPUPWINDOW, $WS_EX_TOPMOST) ; left bar Global $idListview2 = GUICtrlCreateListView("", 0, 0, 17, $iY - 17 - 17) GUICtrlSetStyle($idListview2, BitOR($LVS_ICON, $LVS_NOSCROLL)) GUISetState() Global $hGui3 = GUICreate("", $iX, 17, 0, $iY - 17, $WS_POPUPWINDOW, $WS_EX_TOPMOST) ; bottom bar Global $idListview3 = GUICtrlCreateListView("", 0, 0,$iX, 17) GUICtrlSetStyle($idListview3, BitOR($LVS_ICON, $LVS_NOSCROLL)) GUISetState() Global $hGui4 = GUICreate("", 17, $iY -17 -17, $iX - 17 , 17, $WS_POPUPWINDOW, $WS_EX_TOPMOST) ; right bar Global $idListview4 = GUICtrlCreateListView("", 0, 0,17, $iY -17 -17) GUICtrlSetStyle($idListview4, BitOR($LVS_ICON, $LVS_NOSCROLL)) GUISetState() Global $hImage = _GUIImageList_Create() For $i = 0 To $iColors _GUIImageList_Add($hImage, _GUICtrlListView_CreateSolidBitMap($idListview1, $aColors[$i], 16, 16)) Next _GUICtrlListView_SetImageList($idListview1, $hImage) _GUICtrlListView_SetImageList($idListview2, $hImage) _GUICtrlListView_SetImageList($idListview3, $hImage) _GUICtrlListView_SetImageList($idListview4, $hImage) For $x = 1 To $iNrX _GUICtrlListView_AddItem($idListview1, '', Random(0, $iColors, 1)) _GUICtrlListView_AddItem($idListview3, '', Random(0, $iColors, 1)) Next For $y = 1 To $iNrY _GUICtrlListView_AddItem($idListview2, '', Random(0, $iColors, 1)) _GUICtrlListView_AddItem($idListview4, '', Random(0, $iColors, 1)) Next _GUICtrlListView_SetIconSpacing($idListview1, 16 + 1, 16 + 1) _GUICtrlListView_Arrange($idListview1) _GUICtrlListView_SetIconSpacing($idListview2, 16 + 1, 16 + 1) _GUICtrlListView_Arrange($idListview2) _GUICtrlListView_SetIconSpacing($idListview3, 16 + 1, 16 + 1) _GUICtrlListView_Arrange($idListview3) _GUICtrlListView_SetIconSpacing($idListview4, 16 + 1, 16 + 1) _GUICtrlListView_Arrange($idListview4) _GUICtrlListView_EndUpdate($idListview1) Do _GUICtrlListView_SetItem($idListview1, '', Random(0, $iNrX, 1), 0, Random(0, $iColors, 1)) _GUICtrlListView_SetItem($idListview3, '', Random(0, $iNrX, 1), 0, Random(0, $iColors, 1)) _GUICtrlListView_SetItem($idListview2, '', Random(0, $iNrY, 1), 0, Random(0, $iColors, 1)) _GUICtrlListView_SetItem($idListview4, '', Random(0, $iNrY, 1), 0, Random(0, $iColors, 1)) WinSetOnTop($hGui1, '', 1) WinSetOnTop($hGui2, '', 1) WinSetOnTop($hGui3, '', 1) WinSetOnTop($hGui4, '', 1) Until GUIGetMsg() = $GUI_EVENT_CLOSE

Hi everybody Concerning GUIRegisterMsg, we read this in the Wiki tutorial : There are 2 ways we can still run something long and complicated but still leave the handler quickly: either set a flag or action a dummy control. If we set a flag inside the handler, we can then look for it within our idle loop and run our blocking code from here without affecting the handler at all. If we action a dummy control then we do not even have to look for the flag! Reading this, we might think that the dummy control is a better solution than the flag. But look at the given example : #include <MsgBoxConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> ; Whichever method we use, we need to declare the dummy control or the flag as a Global variable Global $hLeftClick, $fRightClick = False GUICreate("Click me!") ; Create a dummy control for the handler to action $hLeftClick = GUICtrlCreateDummy() GUISetState() ; Register our messages GUIRegisterMsg($WM_LBUTTONUP, "_WM_LBUTTONUP") GUIRegisterMsg($WM_RBUTTONUP, "_WM_RBUTTONUP") While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $hLeftClick ; Our dummy control was actioned so run the required code MsgBox($MB_TOPMOST, "Click", "LEFT CLICK!") EndSwitch ; Look for the flag If $fRightClick = True Then ; Run the code MsgBox($MB_TOPMOST, "Click", "RIGHT CLICK!") ; Do not forget to reset the flag! $fRightClick = False EndIf WEnd Func _WM_LBUTTONUP($hWnd, $iMsg, $wParam, $lParam) ; Action the dummy control GUICtrlSendToDummy($hLeftClick) EndFunc Func _WM_RBUTTONUP($hWnd, $iMsg, $wParam, $lParam) ; Set the flag $fRightClick = True EndFunc * 1st test : left click once in the Gui (dummy control) => MsgBox appears on top Do not close the Msgbox, but left click another couple of times in the Gui, outside the Msgbox. Now only close the Msgbox, what happens ? All the pending left clicks you made will now action the dummy control again & again, with several Msgbox appearing. * 2nd test : right click once in the Gui (flag) => MsgBox appears on top. Do same as 1st test (with right clicks this time) while the Msgbox is on top What happens after you close Msgbox ? Nothing happens (and that's very good), no pending right clicks, no new Msgbox, nothing. That's the reason why I always preferred the flag option

No, with this you search an area. To find a single point (e.g. x=100 y=200) you must set the following values : PixelSearch(100, 200, 100, 200, color, variation) (No guarantee, I almost never work with PixelSearch) also see : understanding-pixelsearch-parameters-and-screen-layout

Just create a standard menu with submenus, and subsubmenus, etc.

Let's start at...

Did you really think, for as long as AutoIt has supported Windows 10 (on systems with Defender), that if this was the case it wouldn't have been advertised far and wide?? In the future, rather than making a definitive statement such as this and then having to come back and retract it, perhaps start by asking a question in the forum about the problems you're encountering.

instead of While use a For Next loop

This is a continuation of Custom drawn TreeViews and ListViews. However, only with respect to listviews. The crucial difference between the new and the old code is that the new code is a complete UDF and therefore much easier to use. Because the UDF is about colors and fonts in listview items and subitems, it's only for listviews in Details or Report view. Main features The UDF supports the following main features. Colors and fonts: 1 Single items/subitems Back colors Fore colors Fonts and styles 2 Colors/fonts for entire columns 3 Alternating colors (entire listview) Alternating colors for rows, columns or both Both default and alternating color can be set Number of rows/columns between color change can be set 4 Custom default colors/font instead of standard default colors/font Custom default back and fore colors can be set for Normal listview items (instead of white and black) Selected listview items (instead of dark blue and white) Unfocused selected items (instead of button face and black) 5 Colors for selected listview items Back and fore colors for selected items when listview has focus Back and fore colors for selected items when listview has not focus Features 1, 2 and 3 cannot be mixed together. 4 and 5 can be mixed with the previous features. 5 extends the functionality of the previous features by adding colors to selected items. 5 cannot be used alone. Listviews: Multiple listviews Native and non-native listviews Native and non-native listview items The UDF can be used with existing listviews WM_NOTIFY message handlers: WM_NOTIFY message handlers can be used completely as usual The UDF can be used with existing WM_NOTIFY message handlers Colors and fonts for single listview items/subitems are stored in an array. The index in this array for a given listview item is stored in ItemParam. Except for this usage of ItemParam nothing in the UDF assumes that listviews or items/subitems are created in a certain way, or that any WM_NOTIFY handlers exists or are designed in a certain way. It should be easy to use the UDF with existing listviews with or without a WM_NOTIFY message handler or other message handlers. WM_NOTIFY message handlers Colors and fonts in listviews are implemented through custom draw notifications in the form of WM_NOTIFY messages. A WM_NOTIFY message handler is needed to implement colors/fonts. If a listview is included in a GUI and a little more than just very basic functionality is wanted, another WM_NOTIFY handler is soon needed to implement this functionality. To register a WM_NOTIFY handler you use the function GUIRegisterMsg. This function can register only one message handler at a time for the same message type. The result of code like this is that only WM_NOTIFY2 message handler is working: GUIRegisterMsg( $WM_NOTIFY, "WM_NOTIFY1" ) ; Register WM_NOTIFY1 GUIRegisterMsg( $WM_NOTIFY, "WM_NOTIFY2" ) ; Register WM_NOTIFY2 (unregisters WM_NOTIFY1) This makes it difficult to implement colors/fonts in a UDF, if you at the same time want to implement advanced functionality in your own code. A solution is to register the WM_NOTIFY message handler, that takes care of custom draw notifications, in a different way. This can be done by a technique called subclassing, which is implemented through the four functions SetWindowSubclass, GetWindowSubclass, RemoveWindowSubclass and DefSubclassProc (coded in WinAPIShellEx.au3). Subclassing Subclassing a window (or control) means to create a message handler for the window, that will receive messages to the window before the original message handler for the window. This section is information on the implementation of a WM_NOTIFY message handler through subclassing: The UDF The UDF is implemented in UDFs\ListViewColorsFonts.au3. This is a list of the most important functions copied from the UDF (around line 200): ; Initiating and exiting ; ---------------------- ; ListViewColorsFonts_Init ; ListViewColorsFonts_Exit ; ; Set colors/fonts for items/subitems ; ----------------------------------- ; ListViewColorsFonts_SetItemColors ; ListViewColorsFonts_SetItemFonts ; ListViewColorsFonts_SetItemColorsFonts ; ; Set colors/fonts for entire listview ; ------------------------------------ ; ListViewColorsFonts_SetColumnColorsFonts ; ListViewColorsFonts_SetAlternatingColors ; ListViewColorsFonts_SetDefaultColorsFonts ; ; Maintenance functions ; --------------------- ; ListViewColorsFonts_Redraw Some of the functions in the complete list in the file are not coded in this version. To use the UDF you first calls ListViewColorsFonts_Init which stores information about the listview and the parent window, and creates the subclass that takes care of the actual drawing of the colors and fonts. Then you call one or more of the ListViewColorsFonts_Set-functions to define the colors and fonts. Depending on the functions you might also need to call ListViewColorsFonts_Redraw. And that's all. Finally you can call ListViewColorsFonts_Exit to remove the subclass before the script exits. If you don't call ListViewColorsFonts_Exit it's called automatically by the UDF. This is the syntax for ListViewColorsFonts_Init and the information about $fColorsFonts flag also copied from ListViewColorsFonts.au3: ; ListViewColorsFonts_Init( $idListView, $fColorsFonts = 7, $iAddRows = 100, $bNative = False ) ; $idListView - Listview control ID or handle ; $fColorsFonts - Specifies options for usage of colors and fonts in the listview. Add required options together. ; 1: Back colors for items/subitems ; Can not be specified separately in this version ; 2: Fore colors for items/subitems ; Can not be specified separately in this version ; 4: Fonts and styles for items/subitems ; Can not be specified separately in this version ; 7: Back and fore colors, fonts and styles ; Flags 1/2/4 are combined in flag 7 in this version ; ; 8: Colors/fonts for entire columns ; ; 16: Alternating row colors (for entire listview) ; 32: Alternating column colors (for entire listview) ; ; 64: Custom default colors and font (for entire listview) ; Custom default back and fore colors can be set for ; - Normal listview items (instead of white and black) ; - Selected listview items (instead of dark blue and white) ; - Unfocused selected listview items (instead of button face and black) ; ; 128: Colors for selected items when listview has focus ; 256: Colors for selected items when listview has not focus The limitations with respect to flags 1, 2 and 4 in this version is only a matter of optimizations. It has nothing to do with features. Drawing of selected items is largely controlled by Windows. A lot of extra code is needed to implement custom colors for selected items through flags 128 and 256. For $fColorsFonts flag is further noted that: ; - Flags 1/2/4 can be combined in a total of seven different ways ; - Flags 1/2/4 (items/subitems), flag 8 (columns) and flags 16/32 (listview) cannot be combined ; - Flag 64 is used to replace the standard default colors/font by custom default colors/font ; Flag 64 can be used alone or in combination with flags 1-32 ; Custom default colors/font must be set before all other colors/fonts ; Flag 64 leads to some restrictions on the features for items/subitems (flags 1/2/4) ; - Flags 128/256 extends the functionality of flags 1-64 by adding colors to selected items ; Flags 128/256 cannot be used alone An array $aListViewColorsFontsInfo is used to store information about the listview, the parent window and the usage of colors/fonts in the listview. For flags 1/2/4 about single items/subitems another array $aListViewColorsFonts is used to store the colors and fonts for the items and subitems. The number of columns in this array depends on whether the flags 128/256 are set or not. The first 160 lines in the UDF contains information about these arrays. For flags 1/2/4 ItemParam field in the listview is used to store the zero based row index in $aListViewColorsFonts for a given listview item. For native listview items created with GUICtrlCreateListViewItem the existing value of ItemParam (control ID) is used as index in an intermediate array $aListViewColorsFonts_Index, and $aListViewColorsFonts_Index holds the index in $aListViewColorsFonts stored as index+1. For non-native listview items the index in $aListViewColorsFonts is stored in ItemParam as -index-20. For non-native listview items an existing value of ItemParam is overwritten. The best way to add colors and fonts to listviews is to put each listview in its own child window. The child window should not contain any other controls, and it should have the same size as the listview. However, this is not a requirement. See the UDF for documentation of the other functions. The implementation of the functions starts in line 230 and onwards. The UDF also contains a group of internal functions. Among other the subclass callback functions to draw the colors and fonts in response to NM_CUSTOMDRAW notifications from the listview. So far the UDF contains seven callback functions which starts around line 2100 and runs over the next 1300 lines nearly to the bottom of the file. The code This section is about some code details related partly to the subclass callback functions and partly to drawing of selected items. Subclass callback functions: Drawing of selected items: In the current version of the UDF the callback function that is implemented to draw single items/subitems ($fColorsFonts = 1/2/4) is the function that can handle all features ($fColorsFonts = 1+2+4 = 7). If only a part of the features is needed, it's possible to create smaller and faster functions, which only implements this part of the features. These functions (six functions in total) are postponed to next version. Features A few comments on the features. The main features in terms of colors and fonts are (a repeat of the list in top of post): 1 Single items/subitems 2 Colors/fonts for entire columns 3 Alternating colors (entire listview) 4 Custom default colors/font instead of standard default colors/font 5 Colors for selected listview items 1, 2 and 3 are features for different kind of elements in the listview and cannot be mixed together. 4 can be used either as an independent feature or mixed with 1, 2 or 3. 5 cannot be used as an independent feature but can only be used together with 1, 2, 3 or 4. 5 extends the functionality of these features by adding colors to selected items. When features 1, 4 and 5 are mixed together, it may look as shown in the following illustrations (screen dumps of examples 3.1 and 4.1 in folder \Examples\5) Selected items\). The first illustration shows how it looks when colors for single items/subitems are mixed with colors for selected items: In the upper picture rows 3-6 are provided with back and fore colors. All subitems in row 3 and 4. Only a few subitems in row 5 and 6. The rows are normal (unselected) rows. In the middle picture rows 2-7 are selected and the listview has focus. Rows 3-6 are also provided with back and fore colors for selected items. In the lower picture rows 2-7 are selected but the listview has not focus. Rows 3-6 are also provided with back and fore colors for selected but unfocused items. In the second illustration the standard default colors are replace with custom default colors. The standard default back and fore colors are: Normal (unselected) items: White and black Selected items in focused listview: Dark blue and white Selected items in unfocused listview: Button face and black These custom default colors are used in the illustration: Normal (unselected) items: Light green and brown Selected items in focused listview: Shiny green (chartreuse) and black Selected items in unfocused listview: Dark green and black Examples Two folders with examples is included in the zip below. The first folder is named Examples and contains examples about the usage of the functions in the UDF. The second folder is named UDF topics and contains examples related to the implementation of the UDF. It's about the use of the subclassing technique as a substitute for a WM_NOTIFY message handler. Particularly about the message flow and performance issues. These examples are addressed in next section. The Examples folder contains these subfolders and files: 0) UDF examples\ - The small examples from the documentation of the functions in the UDF 1) Items-subitems\ - Colors and fonts for single items/subitems 2) Entire columns\ - Colors and fonts for entire columns 3) Alternating colors\ - Alternating row/column colors in an entire listview 4) Custom defaults\ - Replace standard default colors/font with custom defaults 5) Selected items\ - Colors for selected items when listview has focus and has not focus 6) Help file examples\ - Shows how to add colors to a few examples from AutoIt Help file 7) Original examples\ - An implementation of the examples in the old thread with this UDF Listview templates\ - A collection of listview templates ready to add colors/fonts Features demo.au3 - A brief demonstration of all features No colors or fonts.au3 - Reference example All examples runs on Windows XP and later without any performance issues. Folder 1 - 5 demonstrates the five main color/font features listed in top of post. In most of the subfolders you can find a _Readme.txt file with a brief description of the examples. Multiple selections is enabled in most listviews. A few examples will not pass an Au3Check. In particular the examples in subfolder 1 and 2 and the examples in UDF topics folder (see next section) were used to test the subclassing technique as a substitute for a WM_NOTIFY message handler. More information about some of the examples: Examples\0) UDF examples\0) ListViewColorsFonts_Init\Example 1.au3: #include <GUIConstantsEx.au3> #include "..\..\..\UDFs\ListViewColorsFonts.au3" #include "..\..\..\UDFs\GuiListViewEx.au3" Opt( "MustDeclareVars", 1 ) Example() Func Example() ; Create GUI Local $hGui = GUICreate( "ListViewColorsFonts_Init\Example 1", 420, 200, -1, -1, $GUI_SS_DEFAULT_GUI-$WS_MINIMIZEBOX ) ; Create ListView Local $idListView = GUICtrlCreateListView( "", 10, 10, 400, 180, $GUI_SS_DEFAULT_LISTVIEW-$LVS_SINGLESEL, $WS_EX_CLIENTEDGE ) _GUICtrlListView_SetExtendedListViewStyle( $idListView, $LVS_EX_DOUBLEBUFFER+$LVS_EX_FULLROWSELECT ) Local $hListView = GUICtrlGetHandle( $idListView ) ; Reduces flicker ; Add columns to ListView _GUICtrlListView_AddColumn( $idListView, "Column 1", 94 ) _GUICtrlListView_AddColumn( $idListView, "Column 2", 94 ) _GUICtrlListView_AddColumn( $idListView, "Column 3", 94 ) _GUICtrlListView_AddColumn( $idListView, "Column 4", 94 ) ; Fill ListView Local $iItems = 100 For $i = 0 To $iItems - 1 GUICtrlCreateListViewItem( $i & "/Column 1|" & $i & "/Column 2|" & $i & "/Column 3|" & $i & "/Column 4", $idListView ) Next ; Perform initializations to add colors/fonts to single items/subitems ListViewColorsFonts_Init( $idListView, 7 ) ; $fColorsFonts = 7, ( $iAddRows = 100, $bNative = False ) ; Set a green back color for an entire item and a yellow back color for a single cell ListViewColorsFonts_SetItemColors( $idListView, 3, -1, 0xCCFFCC ) ; Green back color for entire item ListViewColorsFonts_SetItemColors( $idListView, 3, 2, 0xFFFFCC ) ; Yellow back color for cell 2 in item ; Force an update of local variables in drawing function ListViewColorsFonts_Redraw( $idListView ) ; Adjust height of GUI and ListView to fit ten rows Local $iLvHeight = _GUICtrlListView_GetHeightToFitRows( $hListView, 10 ) WinMove( $hGui, "", Default, Default, Default, WinGetPos( $hGui )[3] - WinGetClientSize( $hGui )[1] + $iLvHeight + 20 ) WinMove( $hListView, "", Default, Default, Default, $iLvHeight ) ; Show GUI GUISetState( @SW_SHOW ) ; Message loop While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop EndSwitch WEnd ; Delete color/font info for listview ListViewColorsFonts_Exit( $idListView ) GUIDelete() EndFunc UDF topics The examples in UDF topics folder is about the use of subclassing as a substitute for a WM_NOTIFY message handler. Particularly about the message flow and performance issues. These examples illustrates some of the issues, that was discussed in the Subclassing section above, with code. The UDF topics folder contains these subfolders: 1) Subclassing\ - Creating listviews in GUI or child windows? 2) Performance\ - How many listviews can you create in GUI? More information about the examples: Next version In The code section above is already mentioned a number of subclass callback functions which are postponed to next version. The purpose of these additional functions is merely to optimize the code in terms of speed. A number of ListViewColorsFonts_Get-functions to complement the corresponding ListViewColorsFonts_Set-functions are also deferred to next version. For single items/subitems ($fColorsFonts = 1/2/4) colors and fonts are stored in $aListViewColorsFonts array which again is stored in $aListViewColorsFontsInfo. The three functions ListViewColorsFonts_SetItemColors / SetItemFonts / SetItemColorsFonts are used to update $aListViewColorsFonts item by item or subitem by subitem. It would be much faster to update $aListViewColorsFonts directly. Two functions are needed to get a copy of the array from $aListViewColorsFontsInfo and store the array again after the updates. And there is also a need for a couple of examples to illustrate the technique. Examples to dynamically update colors and fonts are missing in this version. Perhaps there is also a need for a few functions to support dynamically updates. For non-native listviews created with _GUICtrlListView_Create it's not uncommon to use ItemParam to store a user defined value. If index in $aListViewColorsFonts is stored in ItemParam, it's no longer possible to use ItemParam for such purposes. A couple of functions to give the user an opportunity to still be able to store a user defined value would be nice. Several global variables are defined in this version. They will be removed in the next version except for a few variables which probably will need to be global in performance terms. If there will be reported any issues or problems in this version, they of course also need to be addressed. The next version should be ready in 2-3 months, and it should also be the final version. Zip file The zip is structured in this way Examples\ UDF topics\ UDFs\ ListViewColorsFonts.au3 GuiImageListEx.au3 GuiListViewEx.au3 NamedColors.au3 OtherColors.au3 NamedColors.au3 contains global constants of named colors copied from .NET Framework Colors Class. You need AutoIt 3.3.10 or later. Tested on Windows 7 32/64 bit and Windows XP 32 bit. Comments are welcome. Let me know if there are any issues. (Set tab width = 2 in SciTE to line up comments by column.) ListViewColorsFonts.7z

Figured it out this morning #NoTrayIcon #include <GuiMenu.au3> #include <GUIConstantsEx.au3> #include <MsgBoxConstants.au3> $hMenu = _GUICtrlMenu_CreatePopup() _GUICtrlMenu_InsertMenuItem($hMenu, 0, "Update", 0) ;Added 0 _GUICtrlMenu_InsertMenuItem($hMenu, 1, "Send Email", 1) ;Added 1 _GUICtrlMenu_InsertMenuItem($hMenu, 2, "Auto Sync", 2) ;Added 2 _GUICtrlMenu_CheckMenuItem($hMenu, 1) _GUICtrlMenu_CheckMenuItem($hMenu, 2) $Form2 = GUICreate("") $Test = GUICtrlCreateButton("Test", 0, 0, 250, 250) GUISetState(@SW_SHOW) While 1 $idMsg = GUIGetMsg() Select Case $idMsg = $GUI_EVENT_CLOSE Exit Case $idMsg = $Test $MenuResult1 = _GUICtrlMenu_TrackPopupMenu($hMenu, $Form2, -1, -1, 1, 1, 2) ConsoleWrite($MenuResult1 & @CRLF) EndSelect WEnd