Leaderboard

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

Thanks a lot @mLipok and @water , I see that you both suggest the same solution of using Execute(), and since it works well for what I need then it's OK also for me . What I'm playing with is a way to pass obj of the browser from a script to another: since you can't pass an object from one script to another as a parameter, I needed a way to retrieve an obj from an xPath so that I can pass the xPath instead of the obj (it's a simple string and can be passed) and then retrieve again the obj from the xPath from the receiving script. This should work for browser objects. In short, in the following script I have 2 functions: getPathTo() a recursive function that gets the xPath of the passed obj getElementByXpath() retrieves the obj from the xPath created by the previous. (this simple function works ONLY with the specific xPaths created by getPathTo(). It is not intended for generic xPaths) here I use those 2 functions within the same script just for testing, but I will use getPathTo() in one script and getElementByXpath() in another script. in the following test script I've set up a loop that pass any object behind the mouse while hovering the browser (some objects still not detected, but I think is a problem of iframes). I was stuck on the getElementByXpath() function, but using Execute() now i can go ahead... Thanks a lot again mLipok and Water. #include <IE.au3> #include <WinAPI.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <array.au3> Local $oIE = _IECreate("www.google.com") Local $oDoc = _IEDocGetObj($oIE) Local $oIE_hwnd = _IEPropertyGet($oIE, "hwnd") Local $oElement, $oElement_save, $aMousePos Local $aBrowserPos[6] ; x , y , width , height , x right , y bottom Local $aOverlayPos[4] ; coordinates of the overlay frame ; Create a Phantom window with a visible frame Local $aParentPos, $AlphaKey = 0xABABAB Local $iBorderColor = 0x00FF00, $iBorderThickness = 3 $hOverlay = GUICreate("", -50, -50, 10, 10, $WS_POPUPWINDOW, $WS_EX_LAYERED + $WS_EX_TOPMOST) ; transparent $Panel = GUICreate("", 48, 48, 10, 10, $WS_CHILD + $WS_VISIBLE, -1, $hOverlay) ; this new window becomes a child of $hOverlay window GUISetBkColor($iBorderColor, $hOverlay) GUISetBkColor($AlphaKey, $Panel) _WinAPI_SetLayeredWindowAttributes($hOverlay, $AlphaKey, 0, $LWA_COLORKEY) GUISetState(@SW_SHOW, $hOverlay) While WinExists($oIE_hwnd) $aMousePos = MouseGetPos() ; Now we get reference to the DOM object behind the mouse pointer ; If IsObj($oDoc) Then $oElement = $oDoc.elementFromPoint($aMousePos[0] - $oIE.document.parentwindow.screenLeft, $aMousePos[1] - $oIE.document.parentwindow.screenTop) If IsObj($oElement) And $oElement <> $oElement_save Then $oElement_save = $oElement $aBrowserPos[0] = Int($oIE.document.parentwindow.screenLeft) ; X position on the desktop of the left edge of the browser $aBrowserPos[1] = Int($oIE.document.parentwindow.screenTop) ; Y position on the desktop of the top border of the browser $aBrowserPos[2] = Int($oIE.document.documentElement.clientWidth) ; Width of browser's client area $aBrowserPos[3] = Int($oIE.document.documentElement.clientHeight) ; Height of browser's client area $aBrowserPos[4] = $aBrowserPos[0] + $aBrowserPos[2] ; X position on the desktop of the right border of the browser $aBrowserPos[5] = $aBrowserPos[1] + $aBrowserPos[3] ; Y position on the desktop of the bottom border of the browser ; $oRect = $oElement.getBoundingClientRect() ; coordinates of the DOM object within the client area of the browser ; $aOverlayPos[0] = Int($oRect.left) + $aBrowserPos[0] ; X position of the left overlay border (absolute desktop coordinates) If $aOverlayPos[0] < $aBrowserPos[0] Then $aOverlayPos[0] = $aBrowserPos[0] ; if left border of the DOM obj is out of browser, overlay border stays anyway within the screen $aOverlayPos[1] = Int($oRect.Top) + $aBrowserPos[1] ; Y position of the top overlay border If $aOverlayPos[1] < $aBrowserPos[1] Then $aOverlayPos[1] = $aBrowserPos[1] ; if top border of obj is out of browser, overlay border stays anyway within the screen $aOverlayPos[2] = Int($oRect.right - $oRect.left) ; width of the obj If $aOverlayPos[0] + $aOverlayPos[2] > $aBrowserPos[4] Then $aOverlayPos[2] = $aBrowserPos[4] - $aOverlayPos[0] ; if obj's width is out of bounds, force the edge within the browser $aOverlayPos[3] = Int($oRect.bottom - $oRect.top) ; Height of the obj If $aOverlayPos[1] + $aOverlayPos[3] > $aBrowserPos[5] Then $aOverlayPos[3] = $aBrowserPos[5] - $aOverlayPos[1] ; stay within browser's bounds ; WinMove($hOverlay, "", $aOverlayPos[0], $aOverlayPos[1], $aOverlayPos[2], $aOverlayPos[3]) $aParentPos = WinGetPos($hOverlay) ; x, y, width, height WinMove($Panel, "", $iBorderThickness - 1, $iBorderThickness - 1, Int($aParentPos[2] - $iBorderThickness * 2), Int($aParentPos[3] - $iBorderThickness * 2)) ; ----- test of functions ----- $sxPath = getPathTo($oElement) ConsoleWrite($sxPath & @CRLF) $TargetObject = getElementByXpath($oIE.document, $sxPath) If IsObj($TargetObject) Then ConsoleWrite(IsObj($TargetObject) & @CRLF & $TargetObject.tagName & @TAB & $TargetObject.OuterText & @CRLF & "--------------" & @CRLF) EndIf ; ----------------------------- EndIf ; EndIf WEnd ; get xPath of an element ; http://stackoverflow.com/questions/2631820/im-storing-click-coordinates-in-my-db-and-then-reloading-them-later-and-showing/2631931#2631931 ; answer by Scott Izu Func getPathTo($oElement) If $oElement.tagName = 'HTML' Then Return '/HTML[0]' If $oElement = $oElement.document.body Then Return '/HTML[0]/BODY[0]' Local $ix = 0, $sibling Local $siblings = $oElement.parentNode.childNodes; For $sibling In $siblings If ($sibling = $oElement) Then Return getPathTo($oElement.parentNode) & '/' & $oElement.tagName & '[' & ($ix) & ']' EndIf If ($sibling.nodeType = 1 And $sibling.tagName = $oElement.tagName) Then $ix += 1 Next EndFunc ;==>getPathTo ; returns the obj from the xPath created by the previous getPathTo() function ; https://www.autoitscript.com/forum/topic/107337-ieau3-can-i-get-a-specific-object-using-an-xpath/?do=findComment&comment=757505 ; syntax by DaleHohm Func getElementByXpath($oDocument, $sxPath) Local $array = StringSplit($sxPath, "/") ; xPath to array ; _ArrayDisplay($array) Local $sPath, $iPos, $sTag, $iTagNdx For $i = 2 To $array[0] $iPos = StringInStr($array[$i], "[") $sTag = StringLeft($array[$i], $iPos - 1) $iTagNdx = Number(StringMid($array[$i], $iPos + 1, StringLen($array[$i]) - $iPos - 1)) $sPath &= '.getElementsByTagname("' & $sTag & '").item(' & $iTagNdx & ')' Next $0bj = Execute("$oDocument" & $sPath) ; <--- Thanks to mLipok and WATER ; ConsoleWrite($sPath & @TAB & IsObj($0bj) & @CRLF) Return $0bj EndFunc ;==>getElementByXpath

This works: #include <Word.au3> $oWord = _Word_Create() ConsoleWrite("1> " & $oWord.Name & @CRLF) ConsoleWrite("2> " & _PropertyGet($oWord, "Name") & @CRLF) Exit Func _PropertyGet($oObject, $sProperty) Return Execute("$oObject." & $sProperty) EndFunc ;==>_PropertyGet

Perfect. I modified my example to reflect the field names you want (KEY, DATA1, DATA2, DATA3). I also added a msgbox popup to show the SELECT statement being used against the MDB. The result(s) from a query are returned as an array. You could then pick out what you want from the array or optimize the results array and write to a file. Are you familiar with using arrays? Also, I just threw the UDF into and example in one script. If you visit the link I posted to the old UDF you can see when they are separated the usage is a little clearer. There are also clearer example comments. I may spend some time cleaning up the UDF and bringing it up to my current scripting standards.

dmob, More than happy to wait for the reports, so do take your time. I have spent the past few days completely rewriting a lot of the editing code within the UDF to make setting the edit/combo/DTP mode more intuitive - and to have a degree of commonality in how they all react to user keystrokes. I am very pleased with it so far and the new code will make adding any further controls (IP address or Slider perhaps?) to the possible editing choices very much easier. I will try and release an Alpha version for others to test tomorrow. M23

Use _FFTabClose

For some objects you can use: https://msdn.microsoft.com/en-us/library/ms536430(v=vs.85).aspx or try to us this: Func GetAttribute($oObject, $sAttribute) Local $Peekattribute = $oObject.$sAttribute ; < - - - - how To ????? ; the following even doesn't works on my system ; Local $Peekattribute = $oObject.getAttribute($sAttribute) ; Local $Peekattribute = $oObject.getAttribute($oObject.item(1)) $Peekattribute = Execute("$oObject." & $sAttribute) Return $Peekattribute EndFunc ;==>GetAttribute Try also: https://msdn.microsoft.com/en-us/library/ff975196(v=vs.85).aspx