Leaderboard

Hello Community, let me introduce you to one of my latest projects (with several more in the pipeline), the BIC - Batch-Image-Cropper BIC is a Batch-Image-Cropper program. It will read all of the following file-types from a given directory: *.bmp;*.jpg;*.jpeg;*.png;*.gif;*.tiff;*.emf;*.wmf;*.ico Then it will cycle through all files and show you a cropping mask to crop the images. It supports freeform rotation of the input images (press f) and a lot of additional hotkeys to speed up processing (press ? for a full list). It will not change the input images, but save all cropped images to a dedicated “_BIC” sub-directory. Sorting out the results is totally up to you. Supported output formats currently are JPG, PNG and BMP. For JPG creation BIC can use sub-binaries. JPGE is used to create JPGs from temporary PNGs, as GDI+ enforces chroma sub-sampling by default and might change colors. ExifTool can be used to copy EXIF data from input JPGs to output JPGs. Thanks to GreenCan and his Visual Image Crop (GUI), which was the starting point for BIC. The executable and the source can be downloaded from my site: https://funk.eu Enjoy, let me know what you think of SMF and with Best Regards

UI Automation Events In standard Windows GUI code, you can respond to Windows messages by registering and implementing a message handler function. A WM_NOTIFY message handler is registered and implemented in this way: ; Registration GUIRegisterMsg( $WM_NOTIFY, "WM_NOTIFY" ) ; Implementation Func WM_NOTIFY( $hWnd, $iMsg, $wParam, $lParam ) ; Code EndFunc The WM_NOTIFY function is a callback function. In UI Automation code, you can respond to UI Automation events by registering and implementing an event handler object. A FocusChangedEventHandler object is registered and implemented in this way: ; Registration UIAEH_FocusChangedEventHandlerCreate() $oUIAutomation.AddFocusChangedEventHandler( 0, $oUIAEH_FocusChangedEventHandler ) ; Implementation ; This is the function that receives events Func UIAEH_FocusChangedEventHandler_HandleFocusChangedEvent( $pSelf, $pSender ) ; Code EndFunc $oUIAEH_FocusChangedEventHandler is the event handler object. It's a callback object. This thread is about how to respond to UI Automation events by registering, implementing and using event handler objects. User Defined Functions Registering and implementing the event handler object in the code above is very simple. To make it that simple, it's necessary to include a few functions in a UDF. The zip-file at bottom of post contains a UIAEH_FocusChangedEventHandler.au3 UDF that allows the registration and implementation of the event handler object as simple as shown above. UIAEH_FocusChangedEventHandlerCreate() is a function in this UDF. The function creates the $oUIAEH_FocusChangedEventHandler object. Because this is a callback object it must be implemented through ObjectFromTag() (coded in ObjectFromTag.au3 in zip-file) function by trancexx and not through the usual ObjCreateInterface() which is used to create other UI Automation objects. (The warning at top of the help text is much more an error in the help text than an error in the function. Thousands of examples show that ObjCreateInterface() works flawlessly.) You don't need to use ObjectFromTag() in your own code. This function is completely handled in the UDFs. UIAEH_FocusChangedEventHandler_HandleFocusChangedEvent() is the function that receives events. This function is coded but commented out in UIAEH_FocusChangedEventHandler.au3. Copy this function to your own code. See FocusChangedEventHandler example below. UIA Event Handlers The first version of Microsoft's UI Automation code (the Windows 7 version that works on Windows XP, Windows Vista, Windows 7 and all later versions) implements four different event handler objects. In addition to the FocusChangedEventHandler object, it's the AutomationEventHandler, PropertyChangedEventHandler and StructureChangedEventHandler objects. The zip-file at the bottom contains the corresponding three event handler UDFs. By the way, these four event handlers are implemented in AutoIt several years ago in this and the following posts. FocusChangedEventHandler exposes a method to handle events that are raised when the keyboard focus moves to another UI Automation element. AutomationEventHandler exposes a method to handle Microsoft UI Automation events. These events include MenuOpened ($UIA_MenuOpenedEventId) and Window_WindowOpened ($UIA_Window_WindowOpenedEventId) events. See module UIA_EventIds in UIA_Constants.au3 for a complete list. Note that EventIds that belong to Windows 8 or later cannot be used in this version of the event handler. But they can be used after code updates over the coming weeks. 2019-12-15 If you select Desktop, AutomationEvent and all Events (Event Ids) in UI Automation Event Monitor below and click Start, you'll see the following output in SciTE console: $oUIAEH_AutomationEventHandler OK Desktop: AddAutomationEventHandler() = AsyncContentLoaded OK Desktop: AddAutomationEventHandler() = AutomationFocusChanged ERR Desktop: AddAutomationEventHandler() = AutomationPropertyChanged OK Desktop: AddAutomationEventHandler() = InputDiscarded OK Desktop: AddAutomationEventHandler() = InputReachedOtherElement OK Desktop: AddAutomationEventHandler() = InputReachedTarget OK Desktop: AddAutomationEventHandler() = Invoke_Invoked OK Desktop: AddAutomationEventHandler() = LayoutInvalidated OK Desktop: AddAutomationEventHandler() = MenuClosed OK Desktop: AddAutomationEventHandler() = MenuModeEnd OK Desktop: AddAutomationEventHandler() = MenuModeStart OK Desktop: AddAutomationEventHandler() = MenuOpened OK Desktop: AddAutomationEventHandler() = Selection_Invalidated OK Desktop: AddAutomationEventHandler() = SelectionItem_ElementAddedToSelection OK Desktop: AddAutomationEventHandler() = SelectionItem_ElementRemovedFromSelection OK Desktop: AddAutomationEventHandler() = SelectionItem_ElementSelected OK Desktop: AddAutomationEventHandler() = StructureChanged OK Desktop: AddAutomationEventHandler() = Text_TextChanged OK Desktop: AddAutomationEventHandler() = Text_TextSelectionChanged OK Desktop: AddAutomationEventHandler() = ToolTipClosed OK Desktop: AddAutomationEventHandler() = ToolTipOpened OK Desktop: AddAutomationEventHandler() = Window_WindowClosed OK Desktop: AddAutomationEventHandler() = Window_WindowOpened OK Note the error for the AutomationFocusChanged event handler (at the top of the list). I've found that there is an error, but so far have no explanation for it. PropertyChangedEventHandler exposes a method to handle Microsoft UI Automation events that occur when a property is changed. These events include Name ($UIA_NamePropertyId) and ValueValue ($UIA_ValueValuePropertyId) changes. See module UIA_PropertyIds in UIA_Constants.au3 for a complete list. Note that PropertyIds that belong to Windows 8 or later cannot be used in this version of the event handler. But they can be used after code updates over the coming weeks. StructureChangedEventHandler exposes a method to handle events that occur when the Microsoft UI Automation tree structure is changed. This event handler seems to be more valuable in eg. screen readers than in usual UI Automation code. NotificationEventHandler exposes a method to handle Microsoft UI Automation notification events. See this post. FocusChangedEventHandler example This is full code in Examples\FocusChangedEventHandlerEx.au3. Run the code in SciTE with F5. #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 "..\Includes\UIAEH_FocusChangedEventHandler.au3" Example() Func Example() UIAEH_FocusChangedEventHandlerCreate() If Not IsObj( $oUIAEH_FocusChangedEventHandler ) Then Return ConsoleWrite( "$oUIAEH_FocusChangedEventHandler ERR" & @CRLF ) ConsoleWrite( "$oUIAEH_FocusChangedEventHandler OK" & @CRLF ) Local $oUIAutomation = ObjCreateInterface( $sCLSID_CUIAutomation, $sIID_IUIAutomation, $dtag_IUIAutomation ) If Not IsObj( $oUIAutomation ) Then Return ConsoleWrite( "$oUIAutomation ERR" & @CRLF ) ConsoleWrite( "$oUIAutomation OK" & @CRLF ) Local $iError = $oUIAutomation.AddFocusChangedEventHandler( 0, $oUIAEH_FocusChangedEventHandler ) If $iError Then Return ConsoleWrite( "AddFocusChangedEventHandler() ERR" & @CRLF ) ConsoleWrite( "AddFocusChangedEventHandler() OK" & @CRLF ) HotKeySet( "{ESC}", "Quit" ) While Sleep(10) WEnd EndFunc Func Quit() UIAEH_FocusChangedEventHandlerDelete() Exit EndFunc ; This is the function that receives events Func UIAEH_FocusChangedEventHandler_HandleFocusChangedEvent( $pSelf, $pSender ) ; Ret: long Par: ptr ConsoleWrite( @CRLF & "UIAEH_FocusChangedEventHandler_HandleFocusChangedEvent: " & $pSender & @CRLF ) Local $oSender = ObjCreateInterface( $pSender, $sIID_IUIAutomationElement, $dtag_IUIAutomationElement ) $oSender.AddRef() ConsoleWrite( "Title = " & UIAEH_GetCurrentPropertyValue( $oSender, $UIA_NamePropertyId ) & @CRLF & _ "Class = " & UIAEH_GetCurrentPropertyValue( $oSender, $UIA_ClassNamePropertyId ) & @CRLF & _ "Ctrl type = " & UIAEH_GetCurrentPropertyValue( $oSender, $UIA_ControlTypePropertyId ) & @CRLF & _ "Ctrl name = " & UIAEH_GetCurrentPropertyValue( $oSender, $UIA_LocalizedControlTypePropertyId ) & @CRLF & _ "Handle = " & "0x" & Hex( UIAEH_GetCurrentPropertyValue( $oSender, $UIA_NativeWindowHandlePropertyId ) ) & @CRLF & _ "Value = " & UIAEH_GetCurrentPropertyValue( $oSender, $UIA_ValueValuePropertyId ) & @CRLF ) Return 0x00000000 ; $S_OK #forceref $pSelf EndFunc ; Auxiliary function (for simple properties only) ; There must be only one instance of this function Func UIAEH_GetCurrentPropertyValue( $oSender, $iPropertyId ) Local $vPropertyValue $oSender.GetCurrentPropertyValue( $iPropertyId, $vPropertyValue ) Return $vPropertyValue EndFunc Test the code by opening the Desktop context menu and move the mouse over the menu items. When the mouse hovers over a menu item it gets focus. Exit with Esc. AutomationEventHandlerEx.au3 Test the example by opening some windows, menus and tooltips. PropertyChangedEventHandlerEx.au3 Open Windows Task Manager (Ctrl+Shift+Esc) and you'll get a whole bunch of property changed events. Note that to access Windows Task Manager (and other programs) on Windows 10, use #RequireAdmin in the script and run SciTE as administrator. StructureChangedEventHandlerEx.au3 Clicking on a folder in File/Windows Explorer treeview generates a lot of structure changed events. New examples will be added over the coming weeks. UI Automation Event Monitor UI Automation Event Monitor is a tool to detect UI Automation events. The first group of toolbar buttons is used to set up the UI Automation event handler. The images have a PropertyChangedEventHandler set up to monitor Name ($UIA_NamePropertyId) and ValueValue ($UIA_ValueValuePropertyId) property changes in Windows Task Manager. Note that to access Windows Task Manager (and other programs) on Windows 10, use #RequireAdmin in the script (UIAEHEvents.au3) and run SciTE as administrator. These four toolbar buttons are hot-track enabled with the technique used in this example. The buttons open four listviews to set up the event handler. All listviews have multiple selections enabled. Select multiple items at once and check a single item in/out to check all selected items in/out. Use mouse or Space key to check an item in/out. In the first image, the mouse hovers over the Top Windows button so that it's selected. In the second image, the Top Windows button is clicked so that the listview is opened. Moving the mouse over the next three buttons automatically opens the corresponding listviews due to hot-tracking. Click the toolbar button again to close the listview or move the mouse above the title bar. Windows Task Manager is checked in the Top Windows listview. The Event Handlers listview is enabled when a Top Window is checked. The Event Ids listview is enabled when the AutomationEvent event handler is checked. The Property Ids listview is enabled when the PropertyChanged event handler is checked. In Event Ids and Property Ids listview you can select an item by pressing the first letter on the keyboard. The second group of toolbar buttons is used to Start/Stop the event handler (or multiple event handlers), Pause/Continue updating the Events listview, and Clear the listview. Note that the Pause button only stops updating the listview. Events are still detected and stored in $aEvents array. All new events are added at the bottom of the listview when you click Continue or Stop. The Pause Main Loop button is used to stop the GUI main loop, which significantly increases the performance of the Events listview. When the GUI main loop is paused you can only click the Continue Main Loop button (same button as Pause Main Loop) and you can close the GUI. Events listview The Events listview is a virtual listview because of performance and to make it easy to constantly add new rows to the bottom of the listview. Nevertheless, there can still be performance issues when a lot of events are generated. To remedy these issues, it's possible to stop the GUI main loop with the Pause Main Loop button. This significantly increases the performance of the Events listview. When there are a large number of events (when many new rows are added quickly at the bottom of the listview), this procedure must be followed to stop the event handler (or multiple event handlers): Make sure the GUI main loop isn't paused. Click the Pause button (second toolbar group) to pause Events listview updates. Click the Stop button to stop the event handler. When there are a small number of events you can immediately click the Stop button. To test the UI Automation Event Monitor, try performing the four examples (in Examples\, briefly described above) through the monitor GUI. There'll probably be some GUI updates in the coming weeks. UIA Menu, Tooltip and Window Events Monitor is a simpler version of UI Automation Event Monitor that detects only MenuOpened, ToolTipOpened and Window_WindowOpened events (AutomationEvents). Updates Windows 8, Windows 8.1 and Windows 10 updates Threads UI Automation UDFs contains all include files. UIASpy - UI Automation Spy Tool is a GUI tool that provides information about windows and controls and their interconnection and provides functionality to generate sample code. UIASpy is essential for creating UI Automation code. In Using UI Automation Code in AutoIt you can find and download examples and read information about using UIA code. IUIAutomation MS framework automate chrome, FF, IE, .... created by junkew August 2013 is the first AutoIt thread on UIA code. Zip-file The zip contains source files for GUIs and examples. Note that UI Automation UDFs must be installed in the Includes folder. You need AutoIt 3.3.12 or later. Tested on Windows 7 and Windows 10. Note that under Windows 7 and earlier versions, only the original four event handlers (AutomationEventHandler, FocusChangedEventHandler, PropertyChangedEventHandler, StructureChangedEventHandler) introduced in Windows 7 can be used. Comments are welcome. Let me know if there are any issues. UIAEHEvents.7z

In a Windows GUI like an AutoIt GUI, functionality and user actions are largely controlled through Windows messages. Therefore, it's interesting to monitor Windows messages. That's the purpose of this example. How does it work? This is a simple example (Examples\1) Native controls\GUICtrlCreateButton.au3): #include <GUIConstantsEx.au3> #include "..\..\Includes\WinMsgMon_Button.au3" ; <<<<<<<<<<<<<<<<<<<< WinMsgMon_InitMsgs( "..\..\Includes" ) ; <<<<<<<<<<<<<<<<<<<< Example() Func Example() ; Create a GUI with various controls. Local $hGUI = GUICreate("Example", 300, 200) WinMsgMon_GetMsgs( $hGUI, "$hGUI" ) ; <<<<<<<<<<<<<<<<<<<< ; Create button controls. Local $idMsgBox = GUICtrlCreateButton("Open MsgBox", 120, 170, 85, 25) WinMsgMon_GetMsgs( $idMsgBox, "$idMsgBox" ) ; <<<<<<<<<<<<<<<<<<<< Local $idClose = GUICtrlCreateButton("Close", 210, 170, 85, 25) WinMsgMon_GetMsgs( $idClose, "$idClose" ) ; <<<<<<<<<<<<<<<<<<<< ; Display the GUI. GUISetState(@SW_SHOW, $hGUI) ; Loop until the user exits. While 1 Switch GUIGetMsg() Case $idMsgBox WinMsgMon_UserMsg( $idMsgBox, $WM_USER0, _ ; <<<<<<<<<<<<<<<<<<<< "Before MsgBox" ) MsgBox( 0, "Title", "One second timeout", 1 ) WinMsgMon_UserMsg( $idMsgBox, $WM_USER1, _ ; <<<<<<<<<<<<<<<<<<<< "After MsgBox" ) Case $GUI_EVENT_CLOSE, $idClose WinMsgMon_UserMsg( $idClose, $WM_USER0, _ ; <<<<<<<<<<<<<<<<<<<< "Before ExitLoop" ) ExitLoop EndSwitch WEnd ; Delete GUI and all controls. GUIDelete($hGUI) WinMsgMon_ViewMsgs( Example ) ; <<<<<<<<<<<<<<<<<<<< EndFunc ;==>Example Include UDF In this example WinMsgMon UDF is included as WinMsgMon_Button.au3 and not just WinMsgMon.au3. Because this is a button example, WinMsgMon_Button.au3 is included to be able to get detail information about button messages. WinMsgMon_InitMsgs() WinMsgMon_InitMsgs() is called immediately after inclusion of the UDF. The function sets up the path used to find text files with message information. In addition to the path, WinMsgMon_InitMsgs() can take an optional $iFlags parameter as input. See WinMsgMon.au3 and Rerun in Toolbar buttons section for more information. WinMsgMon_GetMsgs() WinMsgMon_GetMsgs() is the central function that collects messages. It takes two parameters: A window or control and optionally the name of the window or control. In the example above the function is called three times to be able to collect messages sent to the main GUI and two buttons. While messages are collected and stored, info is simultaneously written to SciTE console. The specified window or control names are used in console output and in WinMsgMon GUI. If no names are specified, the names Window1, Button1 and Button2 are used instead. WinMsgMon_UserMsg() WinMsgMon_UserMsg() sends user messages to the two buttons. 16 user messages are defined: $WM_USER0 - $WM_USERF. In the example $WM_USER0 and $WM_USER1 are send to $idMsgBox button before and after the MsgBox is opened and closed. And $WM_USER0 is send to $idClose button immediately before ExitLoop. This way it's easy to recognize the button clicks among the messages. WinMsgMon_ViewMsgs() WinMsgMon_ViewMsgs() is the central function that displays the messages in WinMsgMon GUI. In the example WinMsgMon_ViewMsgs() is called with Example function as parameter. The function parameter is optional and is used in relation to the Rerun button to be able to run Example once more. See Rerun in Toolbar buttons section. WinMsgMon_ViewMsgs() is called as the last line in Example() function. It does not necessarily have to be the last line. But it must definitely be after GUIDelete(). WinMsgMon_ViewMsgs() may well be called before a final long term calculation or file update. In simple situations you may have sufficient information in SciTE console output. In such cases you can omit the WinMsgMon_ViewMsgs() function. GUI window This is a small part of the messages generated by the example above as shown in WinMsgMon GUI: First column in main listview is message number. Note that the message number in first and second row is 220 and 225. This is because some messages eg. WM_MOUSEMOVE are unchecked in WM_MESSAGEs toolbar listview and therefore not displayed in main listview. Second column shows the window or control that receives the message. Name of idMsgBox button, of interest here, is written on a wheat colored background. Message column shows WM_MESSAGEs and control messages. Some messages are particularly interesting. They are written on a colored background. Notification column displays notifications contained in WM_NOTIFY and WM_COMMAND messages. The info columns shows information provided along with the messages. Console output The same messages as shown in SciTE console (long lines shortened): [ 220] idMsgBox WM_PAINT [ 221] idMsgBox WM_NCHITTEST [ 222] idMsgBox WM_SETCURSOR [ 223] hGUI WM_SETCURSOR [ 224] idMsgBox WM_MOUSEMOVE [ 225] hGUI WM_NOTIFY BCN_HOTITEMCHANGE From = idMsgBox HICF_ENTERING [ 226] idMsgBox WM_PAINT [ 227] idMsgBox WM_ERASEBKGND [ 228] hGUI WM_ERASEBKGND [ 229] hGUI WM_CTLCOLORDLG [ 230] hGUI WM_PRINTCLIENT [ 231] hGUI WM_CTLCOLORBTN [ 232] hGUI WM_NOTIFY NM_CUSTOMDRAW From = idMsgBox CDDS_PREERASE [ 233] hGUI WM_NOTIFY NM_CUSTOMDRAW From = idMsgBox CDDS_PREPAINT [ 234] idMsgBox WM_GETTEXTLENGTH [ 235] idMsgBox WM_GETTEXT [ 236] idMsgBox WM_USER1 [ 237] idMsgBox WM_PAINT Toolbar listviews The five toolbar buttons before the first separator opens five listviews. The buttons are hot-track enabled with the technique used in this example. Wins/Ctrls In Wins/Ctrls listview you check the window or control where from you want to see messages. Here messages from all windows and controls are shown: Because some messages eg. WM_MOUSEMOVE are unchecked only 742 of 1315 messages are shown. Click the checkmark or select the row and press Space key to show all messages. When a row is checked, main listview is updated instantly. Unchecked messages in other toolbar listviews are reset. See Set in Toolbar buttons section for an easy way to uncheck messages. Click the color cell or select the row and press Enter key to set background color. The combo control is implemented with the technique demonstrated in this example. The background color for all windows and controls (first row) cannot be set. Note that only single selection is enabled in this toolbar listview. In the other four listviews multiple selections are enabled. To close a toolbar listview click in main listview, click the toolbar button, move mouse pointer above titlebar or press Esc. WM_MESSAGEs In WM_MESSAGEs listview you uncheck messages that you don't want to see. WM_MOUSEMOVE and WM_NCHITTEST messages are already unchecked. WM_NOTIFY messages are written on an aquamarine background: To uncheck or set background color for all WM_NC-messages select the six rows and press Space or Enter key. When a message is un- or in-checked nothing happens until the listview is closed. Then the Refresh button is enabled. Before you click the Refresh button you can un- or in-check messages in other listviews. Click Refresh button to update main listview. When a color is set main listview is updated instantly. Control Msgs The Control Msgs listview is used to manage control messages: WM_0xC09B is an application defined and unregistered message and is shown as the message code. The two user messages are written on a tomato red background. WM_NOTIFYs and WM_COMMANDs WM_NOTIFYs and WM_COMMANDs listviews are used to manage notifications contained in WM_NOTIFY and WM_COMMAND messages. Toolbar listviews 2 - 5 Messages and notifications in toolbar listviews 2 - 5 are grouped by checked/unchecked items. Unchecked items in bottom of listviews. Update 2018-08-15. A Search can be initiated by double-clicking a message or notification in toolbar listviews 2 - 5. Update 2018-08-04. Toolbar buttons Click Refresh to update main listview after messages and notifications are un- or in-checked in toolbar listviews. Click Rerun to run the script and perform message collection once more. A submenu shows up with "Rerun script", "Write messages to console" and "Detail message information" items. The two last items are the same options as can be set through flag values in WinMsgMon_InitMsgs(). In the example in top of post WinMsgMon_ViewMsgs() takes Example as an input parameter. This is the function that will be executed when you click "Rerun script". The function parameter is optional. If not specified, Rerun button is disabled. The Search group is used to search for messages and notifications. When you click the Search button the Search listview shows up. Double click or press Enter key on an item in the listview to start a search. A search for WM_USER1 messages looks this way in main listview: Use Reset button to reset a search. A search can also be initiated by double-clicking a message or notification in toolbar listviews 2 - 5. Update 2018-08-04. Copy button copies text in selected rows to clipboard. Set button applies settings defined in WinMsgMon.ini. See below. A submenu shows up with Uncheck and Colors items. Click Uncheck to uncheck messages defined in ini-file. Colors are already set through GUI creation. Reset shows a submenu with Uncheck, Colors and Search items. Click an item to reset the feature. Use Set button to apply the feature again. Code info A few notes about the code in relation to toolbar listviews and buttons. All listviews are virtual listviews. Through message collection, indexes are created to display data in main listview and to perform searches. Several set of indexes are created. A set for all windows and controls at once. And a set for each single window and control. When a row in Wins/Ctrls toolbar listview (the leftmost listview) is checked, messages are displayed in main listview through one of these precalculated indexes. That's the reason why it's possible to display the messages in the same moment as the row is checked. Search indexes are created for each single message and notification in the Search listview. A set for all windows and controls at once. And a set for each single window and control. That's a lot of search indexes. In the example above, there are around 100 - 150 search indexes. Calculation of indexes is performed through dictionary objects. When you perform a search the matching rows in main listview are instantly drawn with the yellow background color through a precalculated search index. Next and Prev buttons also takes advantage of the indexes. As soon as a message or notification is unchecked in toolbar listviews 2 - 5 none of these precalculated indexes can be used any more. When you click Refresh a new index is calculated to be able to display the messages in main listview. When you start a search a new index is calculated to be able to display matching messages with the yellow background color, and to be able to use Next and Prev buttons. Up to 10,000 messages, performance should not be a problem. So far, no more messages have been tested. Arrays are dimensioned to a maximum of 100,000 messages. The number of windows and controls in leftmost toolbar listview is limited to 20. When you check an item in leftmost toolbar listview all unchecked messages and notifications are reset and the precalculated indexes can be used again. Functions Most functions have already been described through review of the example in top of post. There are only a few left: WinMsgMon_LoadMsgs() When the message flow from an application is monitored, usually only messages for a single control and main GUI is monitored at a time. However, there will nevertheless often be messages from eg. buttons that are very common controls. If button messages are not registered with WinMsgMon_GetMsgs( $idButton ), messages will appear with the code instead of the name. It's actually the notifications that will appear with the code instead of the name. Use WinMsgMon_LoadMsgs() to load notification names this way: #include "..\..\Includes\WinMsgMon.au3" WinMsgMon_InitMsgs( "..\..\Includes" ) WinMsgMon_LoadMsgs( "BCN_Notifications.txt" ) ; Button control notifications WinMsgMon_LoadMsgs( "EN_Notifications.txt" ) ; Edit control notifications WinMsgMon_RemMsgs() WinMsgMon_RemMsgs() removes all message monitors registered with WinMsgMon_GetMsgs(). WinMsgMon_RemMsgs() is called as the first command in WinMsgMon_ViewMsgs(). It's only necessary to call WinMsgMon_RemMsgs() if WinMsgMon_ViewMsg() isn't called. Ie. if the messages are written to SciTE console only. And only if code is executed after GUIDelete(). Detail info Detail info is information in columns named Info 1 - 4 in WinMsgMon GUI. This is information that can be extracted through wParam and lParam parameters in a message handler function. Detail info for WM_NOTIFY and WM_COMMAND messages is always extracted. Detail info for other window and control messages is depending on specific message handlers (script files). In this version only a few message handlers are implemented and only for a limited number of messages. To be able to collect detail info the message handler must be included in the script. In the example in top of post WinMsgMon_Button.au3 is included instead of WinMsgMon.au3 to be able to collect detail info for buttons. WinMsgMon.ini Includes\WinMsgMon.ini is included in the zip-file. If a copy of this file is placed in the same folder as the running script, the copy will be used instead. You can edit the copy to your own needs. An empty file disables all settings in Includes\WinMsgMon.ini. Includes\WinMsgMon.ini: [Apply Settings] Uncheck=True Colors=True [WM_MESSAGEs Uncheck] WM_ERASEBKGND=1 WM_IME_NOTIFY=1 WM_MOUSEMOVE=1 WM_MOVE=1 WM_MOVING=1 WM_NCHITTEST=1 WM_NCMOUSEMOVE=1 WM_PAINT=1 WM_PRINTCLIENT=1 WM_SETCURSOR=1 WM_TIMER=1 WM_WINDOWPOSCHANGED=1 WM_WINDOWPOSCHANGING=1 [WM_MESSAGEs Colors] WM_NOTIFY=Aquamarine WM_COMMAND=Aquamarine WM_KEYDOWN=Bisque WM_KEYUP=Bisque WM_CHAR=Bisque WM_DEADCHAR=Bisque WM_SYSKEYDOWN=Bisque WM_SYSKEYUP=Bisque WM_SYSCHAR=Bisque WM_SYSDEADCHAR=Bisque WM_LBUTTONDOWN=Khaki WM_LBUTTONUP=Khaki WM_LBUTTONDBLCLK=Khaki WM_RBUTTONDOWN=Khaki WM_RBUTTONUP=Khaki WM_RBUTTONDBLCLK=Khaki WM_MBUTTONDOWN=Khaki WM_MBUTTONUP=Khaki WM_MBUTTONDBLCLK=Khaki WM_MOUSEWHEEL=Khaki WM_XBUTTONDOWN=Khaki WM_XBUTTONUP=Khaki WM_XBUTTONDBLCLK=Khaki WM_CONTEXTMENU=LightPink WM_INITMENU=LightPink WM_INITMENUPOPUP=LightPink WM_MENUSELECT=LightPink WM_MENUCHAR=LightPink WM_MENURBUTTONUP=LightPink WM_MENUGETOBJECT=LightPink WM_UNINITMENUPOPUP=LightPink WM_MENUCOMMAND=LightPink WM_ENTERMENULOOP=LightPink WM_EXITMENULOOP=LightPink WM_NEXTMENU=LightPink [Control Messages Uncheck] [Control Messages Colors] WM_USER0=Tomato WM_USER1=Tomato WM_USER2=Tomato WM_USER3=Tomato WM_USER4=Tomato WM_USER5=Tomato WM_USER6=Tomato WM_USER7=Tomato WM_USER8=Tomato WM_USER9=Tomato WM_USERA=Tomato WM_USERB=Tomato WM_USERC=Tomato WM_USERD=Tomato WM_USERE=Tomato WM_USERF=Tomato [WM_NOTIFY Notifications Uncheck] [WM_NOTIFY Notifications Colors] [WM_COMMAND Notifications Uncheck] [WM_COMMAND Notifications Colors] "Uncheck=True" in "Apply Settings" section in WinMsgMon.ini means that unchecked messages are removed from main listview through GUI creation. As soon as an item in Wins/Ctrls toolbar listview (leftmost) is checked the removed messages are redisplayed. Click Set | Uncheck to remove the messages again. "Colors=True" in "Apply Settings" section means that colors are set through GUI creation. Examples Examples\ 1) Native controls - GUICtrlCreate<Control> examples supplied with message monitor code 2) UDF controls - _GUICtrl<Control>_Create examples (not included above) supplied with message monitor code 3) Miscellaneous Combo\ - ComboBox example including the corresponding Edit and ListBox controls. ListView\ - Four ListView examples with a standard ListView, a custom drawn ListView, a virtual ListView and a virtual and custom drawn ListView. Window\ - An example that shows how mouse clicks generates AutoIt messages ($GUI_EVENT_MESSAGEs). Two examples regarding blocked and paused GUIs. Includes Includes\ WinMsgMon.au3 - Main include file, collects messages WinMsgMon_Button.au3 - Button controls, detail information WinMsgMon_ComboBoxEx.au3 - ComboBoxEx controls, detail information WinMsgMon_ListBox.au3 - ListBox controls, detail information WinMsgMon_ListView.au3 - ListView controls, detail information WinMsgMon.ini - ini-file, colors and unchecked messages Internal\ - Internal files, implements the GUI Messages\ - Message info files CTRL_Information.txt - Info file for AutoIt window and 23 controls WM_Messages.txt - Common Windows messages CCM_Messages.txt - Common control messages <???>_Messages.txt - Messages for specific controls WM_NOTIFY\ NM_Notifications.txt - Common Windows notifications <???>_Notifications.txt - WM_NOTIFY notifications for specific controls WM_COMMAND\ <???>_Notifications.txt - WM_COMMAND notifications for specific controls 7z-file The 7z contains source code and message data. You need AutoIt 3.3.12 or later. Tested on Windows 7 and Windows 10. Comments are welcome. Let me know if there are any issues. WinMsgMon.7z

_ReadIniSectionNames is just a little function I whipped up, that I thought I might as well share ... someone might find it useful. I had a need for it due to approaching the 32767 characters limit with the original INI function - IniReadSectionNames (see the Help file if you are not aware of this). Enjoy! Others have been there before me, and no doubt many others have also crafted their own solutions. Here is two old ones I found with a quick search ... both different but kind of similar to mine. I've gone for the simplistic approach. Test Example.au3 NOTE - It should be obvious you need to provide your own INI file and its correct path for the $file variable. #include <Array.au3> #include "ReadIniSectionNames.au3" Local $file = @ScriptDir & "\Settings.ini" Local $names = _ReadIniSectionNames($file) If Not @error Then _ArrayDisplay($names) Else MsgBox(0, "Return Error", $names) EndIf Exit ReadIniSectionNames.au3 Global $i, $INIfile, $INIlines, $INIread, $INIsection, $linetxt, $SectionNames Func _ReadIniSectionNames($INIfile) $INIread = FileRead($INIfile) $INIlines = StringSplit($INIread, @LF, 1) If @error Then Return SetError(1, 0, -1) Else $SectionNames = "" For $i = 1 To $INIlines[0] $linetxt = $INIlines[$i] If StringLeft($linetxt, 1) = "[" Then $INIsection = StringTrimLeft($linetxt, 1) $INIsection = StringStripCR($INIsection) $INIsection = StringTrimRight($INIsection, 1) If $INIsection <> "" Then If $SectionNames = "" Then $SectionNames = $INIsection Else $SectionNames = $SectionNames & "|" & $INIsection EndIf EndIf EndIf Next If $SectionNames = "" Then Return SetError(2, 0, -2) Else $SectionNames = StringSplit($SectionNames, "|", 1) Return $SectionNames EndIf EndIf EndFunc ;=> _ReadIniSectionNames

#RequireAdmin #include <MsgBoxConstants.au3> ESSENTFix() Func ESENTFix() Local $sFilePath = @WindowsDir & "\System32\config\systemprofile\AppData\Local\TileDataLayer\Database" ; If the directory exists the don't continue. If FileExists($sFilePath) Then MsgBox($MB_SYSTEMMODAL, "", "An error occurred. The directory already exists.") Return False EndIf ; Create the directory. DirCreate($sFilePath) ; Display a message of the directory creation. MsgBox($MB_SYSTEMMODAL, "", "The directory has been created.") EndFunc ;--> ESENTFix Changed to the above it says the folders were created but as the picture above they are not made. Also thank you for the help.

If it's any consolation, at the other end of the spectrum are freaks like myself, who tend to (speed)read an entire Help file to get a sense of the scope, modus operandi, and perhaps unsuspected capabilities of a particular piece of software. Having written large Help files myself (and even recorded a series of tutorial videos once), I do commiserate though. Perhaps you can glean some comfort from the fact that your digital footprint will probably outlast any physical one you leave on this Earth...

Whoever said that is silly, any coder with half a brain would know that resizing an array is heaps slower than concatenating a string Anyway, I improved your function by using an Array, but in a different and more efficient way: #include <Array.au3> #include <StringConstants.au3> Global $i, $INIfile, $INIlines, $INIread, $INIsection, $linetxt, $SectionNames Example() Func Example() Local $aSections = _ReadIniSectionNames("Test.ini") _ArrayDisplay($aSections) EndFunc Func _ReadIniSectionNames($INIfile) $INIread = FileRead($INIfile) Local $iSectionCount = StringCount($INIread, '[') Local $aSections[$iSectionCount + 1] $aSections[0] = 0 $INIlines = StringSplit($INIread, @LF, 1) If @error Then Return SetError(1, 0, -1) Else For $i = 1 To $INIlines[0] $linetxt = $INIlines[$i] If StringLeft($linetxt, 1) = "[" Then $INIsection = StringTrimLeft($linetxt, 1) $INIsection = StringStripCR($INIsection) $INIsection = StringTrimRight($INIsection, 1) If $INIsection <> "" Then $aSections[0] += 1 $aSections[$aSections[0]] = $INIsection EndIf EndIf Next If $aSections[0] = 0 Then Return SetError(2, 0, -2) Else If $aSections[0] < $iSectionCount Then ReDim $aSections[$aSections[0] + 1] Return $aSections EndIf EndIf EndFunc ;=> _ReadIniSectionNames Func StringCount($sMasterString, $sString) Local $iPos = 0 Local $iCount = 0 While True $iPos = StringInStr($sMasterString, $sString, $STR_NOCASESENSEBASIC, 1, $iPos + 1) If @error Or $iPos = 0 Then ExitLoop $iCount += 1 WEnd Return $iCount EndFunc

It has been suggested to me, that making $SectionNames an array at the start, and then adding to it, would be faster than concatenating strings and using StringSplit. I did not find that to be the case, and doing so was actually significantly slower ... but maybe I am doing it wrong? Here is what I did, with a 1.09 Mb INI file, that contains 2136 sections. #include <Array.au3> Global $i, $INIfile, $INIlines, $INIread, $INIsection, $linetxt Local $file = "D:\Programs\KindEbook Wishlist\Jumbo (b).ini" Local $names = _ReadIniSectionNames($file) If Not @error Then _ArrayDisplay($names) Else MsgBox(0, "Return Error", $names) EndIf Local $names = _ReadIniSectionNames_2($file) If Not @error Then _ArrayDisplay($names) Else MsgBox(0, "Return Error", $names) EndIf Exit Func _ReadIniSectionNames($INIfile) Local $begin, $diff, $SectionNames $INIread = FileRead($INIfile) $INIlines = StringSplit($INIread, @LF, 1) If @error Then Return SetError(1, 0, -1) Else $begin = TimerInit() $SectionNames = "" For $i = 1 To $INIlines[0] $linetxt = $INIlines[$i] If StringLeft($linetxt, 1) = "[" Then $INIsection = StringTrimLeft($linetxt, 1) $INIsection = StringStripCR($INIsection) $INIsection = StringTrimRight($INIsection, 1) If $INIsection <> "" Then If $SectionNames = "" Then $SectionNames = $INIsection Else $SectionNames = $SectionNames & "|" & $INIsection EndIf EndIf EndIf Next If $SectionNames = "" Then Return SetError(2, 0, -2) Else $SectionNames = StringSplit($SectionNames, "|", 1) $diff = TimerDiff($begin) & " milliseconds" $diff = "Using StringSplit = " & $diff ClipPut($diff) ;MsgBox(0, "Time Taken", $diff) Return $SectionNames EndIf EndIf EndFunc ;=> _ReadIniSectionNames Func _ReadIniSectionNames_2($INIfile) Local $begin, $diff_2, $s $INIread = FileRead($INIfile) $INIlines = StringSplit($INIread, @LF, 1) If @error Then Return SetError(1, 0, -1) Else $begin = TimerInit() Local $SectionNames[1] $s = 0 For $i = 1 To $INIlines[0] $linetxt = $INIlines[$i] If StringLeft($linetxt, 1) = "[" Then $INIsection = StringTrimLeft($linetxt, 1) $INIsection = StringStripCR($INIsection) $INIsection = StringTrimRight($INIsection, 1) If $INIsection <> "" Then $s = $s + 1 _ArrayAdd($SectionNames, $INIsection, 1) EndIf EndIf Next If $s = 0 Then Return SetError(2, 0, -2) Else $SectionNames[0] = $s $diff_2 = TimerDiff($begin) & " milliseconds" $diff_2 = "Using _ArrayAdd = " & $diff_2 $diff = ClipGet() & @LF & $diff_2 ClipPut($diff) MsgBox(0, "Time Taken", $diff) Return $SectionNames EndIf EndIf EndFunc ;=> _ReadIniSectionNames_2 Here are some timing results. None are the same, no doubt due to vagaries of my PC and while connected to the web. Using StringSplit = 475.797265465162 milliseconds Using _ArrayAdd = 6029.33782085074 milliseconds Using StringSplit = 469.701270439278 milliseconds Using _ArrayAdd = 6282.41561636396 milliseconds Using StringSplit = 500.060210392314 milliseconds Using _ArrayAdd = 6137.26802103186 milliseconds Using StringSplit = 484.184327357759 milliseconds Using _ArrayAdd = 6135.25773119869 milliseconds Using StringSplit = 489.524006129172 milliseconds Using _ArrayAdd = 6130.73949420813 milliseconds

Hello This is a sample for create a QR Code using the library Quricol - QR code generator library of Serhiy Perevoznyk. First we must download a package from http://users.telenet.be/ws36637/download/quricol.zip , this file contains sources and documentation for use on Pascal-Delphi system. We need only quricol32.dll (in \quricol\Binaries directory) which must be copied in an accessible directory. I have inferred use and parameters by examining the file \Quricol.Barcode\NativeMethods.cs. The script can create a QR Code in BMP and PNG format or on the screen. I apologize, but I am not be able to insert the QR code in clipboard. In the compressed file there is: - quricol32.dll - ProvaQR.au3 the script test - formhandler.au3 - functions.au3 These last two scripts are needed for the test, in particular formhandler.au3 is a new version of a form generator, not yet inserted in the repository because is yet in test. Best regards John Rossati AutoitQRCode.zip