Leaderboard

I had an interesting accident. (I thing) #include <ButtonConstants.au3> #include <GUIConstantsEx.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> #include <Misc.au3> _ColorsSelection() Func _ColorsSelection() Local $hGUI = GUICreate("Colors Selection", 500, 500, -1, -1, -1) GUISetFont(10) GUICtrlCreateLabel("Red", 10, 10, 101, 17, 0x0002) GUICtrlCreateLabel("Green", 10, 140, 101, 17, 0x0002) Local $Button1 = GUICtrlCreateButton("", 120, 5, 50, 25, 0xFF0000) ; instead of 0x8000 I paste 0xFF0000 GUICtrlSetBkColor(-1, 0xFF0000) Local $Button2 = GUICtrlCreateButton("", 120, 135, 50, 25, 0xFF0000) ; instead of 0x8000 I paste 0xFF0000 GUICtrlSetBkColor(-1, 0x00FF00) GUISetState(@SW_SHOW) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE ExitLoop Case $Button1 ConsoleWrite("$Button1=" & $Button1 & @CRLF) Case $Button2 ConsoleWrite("$Button2=" & $Button2 & @CRLF) EndSwitch WEnd GUIDelete($hGUI) EndFunc ;==>_ColorsSelection

In native.au3 when documenting ControlGetHandle on line 1680 it says, "Returns the control's current text.", but it should be "Retrieves the internal handle of a control." Similarly, ControlGetFocus has the incorrect description text as well. It doesn't bother me, but if you auto-document there may be a bug? If you copy/pasted, then I'm sorry; that's a lot of work!

Maybe this explanation ? 1) Button when no style is indicated at creation (-1) , WS_TABSTOP will be forced (help file) Button style becomes 0x50010000 WS_CHILD, WS_VISIBLE, WS_TABSTOP [0x40000000, 'WS_CHILD'] [0x10000000, 'WS_VISIBLE'] [0x00010000, 'WS_TABSTOP'] 2) Button created with 0xFF0000 style Button style becomes 0x50FF0000 WS_CHILD, WS_VISIBLE, WS_OVERLAPPEDWINDOW, WS_VSCROLL, WS_HSCROLL [0x40000000, 'WS_CHILD'] [0x10000000, 'WS_VISIBLE'] [0x00CF0000, 'WS_OVERLAPPEDWINDOW'] [0x00200000, 'WS_VSCROLL'] [0x00100000, 'WS_HSCROLL'] 'WS_OVERLAPPEDWINDOW' means (WS_CAPTION | WS_SYSMENU | WS_SIZEBOX | WS_MINIMIZEBOX | WS_MAXIMIZEBOX)

Wow this is really kind of interesting. I don't even understand why it's doing that.

New version 0.0.0.31 in last post. Fixed persistence not working correctly. Added message box for persistence with Yes or No option. Again, clicking one adds it to the White or Blacklist files. Usage at 8.3MB RAM

No worries, thank you. I am just about to update for some fixes and improvements anyway. Thank you for checking it out.

You are comparing what you have now with what you'll have in X seconds, all in memory. When you load your script again, it'll do the same. If you saved the last known state, next time you load the script you will know for a fact if anything changed since you last run the script because you have it in a file with the last known state, and not just what changed while running the script That will necessitate comparing each entry and not just a count of how many. Also, as a bad actor, one could replace an entry to keep the count intact or other reasons to just edit an entry. ..unless I've got it wrong ( don't remember the code clearly )

time taken to convert Array to Safearray UBound: 10308 Array_Split: 3.59900051094329 to_Safearray: 10.3791479145815 Now if you delete the code within __Array_to_SafeArray then the time taken just to pass the data through COM objects.... UBound: 10308 Array_Split: 3.74493431229134 to_Safearray: 9.39925668250824 <<============ So it's an AutoIt internal thing; you have to ask Jon. Example code: #include "SafeArray.au3" #include "ArrayPointer UDF.au3" __Example_0A() Func __Example_0A() $s = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris pharetra tristique felis at dapibus. Vivamus odio lorem, feugiat ut porttitor ac, vehicula sed diam. Donec facilisis quam vitae quam sollicitudin tempus. Quisque ligula sapien, convallis in enim quis, porttitor bibendum lacus. Aenean sollicitudin sit amet augue hendrerit tristique. Nam non est sollicitudin lorem semper tempus ac id tellus. Ut id urna sed justo maximus condimentum ut sed nibh. Integer sit amet consectetur leo. Ut consectetur, nisl eget placerat dignissim, quam dolor rutrum lectus, nec sollicitudin nunc ipsum quis turpis. Maecenas venenatis vel neque vitae aliquam. Etiam id elit quis arcu blandit luctus id ac mauris. Etiam cursus bibendum ultricies. Morbi vitae pellentesque eros, at ullamcorper neque. Duis luctus semper euismod. Etiam vel dui sit amet ante faucibus lacinia non et ante. Quisque id mauris ultrices, congue dui vitae, semper justo. Quisque a placerat metus, vitae ultrices massa. Nunc iaculis faucibus quam quis tincidunt. Integer suscipit ullamcorper felis, eu porttitor nibh sodales ut. Aenean quis fermentum nisl. Maecenas vestibulum hendrerit dolor ac ornare. Mauris vulputate nulla ut nunc ultricies faucibus. Vestibulum ligula enim, vestibulum vitae mauris in, vehicula aliquet nibh. Nunc viverra erat massa, nec scelerisque lacus posuere quis. Maecenas nec neque facilisis, malesuada urna a, iaculis sem. Donec volutpat eget enim nec tempus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Pellentesque vitae est elementum, feugiat ligula sit amet, porttitor turpis. Aliquam erat volutpat. Quisque id luctus leo. Vestibulum egestas, nibh id euismod semper, sem tellus dictum metus, nec ullamcorper tellus nisi a sapien. Nunc rutrum, mauris eu lacinia tincidunt, velit augue interdum massa, eu porta odio massa ac ipsum. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Curabitur semper sed dolor ut vulputate. Cras cursus odio eu felis tristique, non fermentum tellus bibendum. Mauris laoreet mattis blandit. Morbi eget viverra diam. Nulla a venenatis enim, vitae ullamcorper nisi. Cras feugiat felis id orci sagittis rhoncus. Proin congue tempor urna id viverra. Aliquam scelerisque leo sit amet justo laoreet pulvinar. Integer risus enim, viverra at tortor nec, egestas rutrum massa. Cras id velit imperdiet, elementum ante sit amet, tincidunt nunc. In facilisis mi a suscipit mollis. Donec ornare ante quis sodales vestibulum. Phasellus eget tellus erat. Sed pellentesque eleifend mauris vel malesuada. Quisque orci felis, fringilla vel tellus et, vestibulum efficitur lacus. Nullam dictum ligula non faucibus fermentum. Pellentesque dignissim, velit in scelerisque luctus, lacus arcu fermentum nulla, vel sodales nibh tortor in elit. Curabitur ut orci varius, scelerisque lectus volutpat, posuere turpis. Integer efficitur arcu nec ornare lobortis. Fusce lobortis, odio ut sodales pulvinar, neque nisl eleifend tortor, in dignissim ipsum purus nec nunc. Vivamus auctor lectus volutpat nunc congue sollicitudin nec eu nisl. Cras elementum auctor ligula, et egestas augue pharetra eu. Nam fermentum condimentum finibus. Aliquam a suscipit sem. Cras pretium neque nec ullamcorper aliquet. Sed vitae condimentum est. Curabitur mattis posuere rhoncus. Sed accumsan, quam nec mollis faucibus, velit odio ornare velit, sit amet fermentum enim." $s = $s & $s & $s $hTime_A = TimerInit() $aArray = StringSplit($s, "", 2) ConsoleWrite(" UBound: " & UBound($aArray)&@CRLF) ConsoleWrite(" Array_Split: " & TimerDiff($hTime_A)&@CRLF) Local $t_SAobj Local $o_SAobj = __SafeArray_Dummy_Obj($t_SAobj) $hTime_B = TimerInit() Local $psa $o_SAobj.Array_to_SafeArray($aArray, $psa) SafeArrayUnaccessData( $psa ) ConsoleWrite(" to_Safearray: " & TimerDiff($hTime_B)&@CRLF) SafeArrayDestroy($psa) $o_SAobj = 0 __Delete_SafeArray_ObjectFromTag( $t_SAobj ) EndFunc for ArrayPointer UDF => https://www.autoitscript.com/forum/topic/213008-array-pointer/

I'm not really sure if I get your question. But I can confirm, that this behavior of the OS Windows is a matter of fact: There is a given file with the original data. There are three timestamps associated with this file object: CreationTime, LastAccessTime, LastWriteTime. I never make use of "lastaccesstime", so the rest of this writing is just about creation an write time. When you *MOVE* the file within the same *DRIVE*, the timestamps are preserved. The reason is, that the file is physically moved, it is the same file after the move When you copy a file, then a new file is created, preserving the timestamp LastWriteTime, but receiving a new timestamp for CreationTime = "point-of-time-of-the-copy-process" When you move a file crossing drive borders, then physically the "move" is done in two steps. Step 1: The file is copied to its new location. Step 2: The original file is deleted afterwards. so the resulting time stamps end up in the situation I described for "when you copy a file". Note: If you connect two different drive letters to the same share, eg. letter F: and G:, and "move" a file from F: to G:, then this will be a "copy-and-delete-original" action. IMHO you need to "transfer" the original timestamp for "CreationTime" manually, when you copy a file and want the new one to reflect the original timestamp. <edit> Note: There is a purely client side registry key, that will enforce a "always-do-a-copy" for network drives. The reason this one was introduced is the dumb fact, that moving a file within one network drive will also move the file's ACL (access control list) with the file. Often ending up in unpredictable access situations. (I moved the file to <folder xy you have access to>: you *MUST* see it now -> no, I don't see it!) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer Name: MoveSecurityAttributes Type: REG_DWORD Value: 0 = Default behavior (security attributes are preserved) 1 = Security attributes are **not** preserved when moving (copy-then-delete behavior)

You could grab the event sent by Excel before a workbook gets closed. Something like this: #include <Excel.au3> HotKeySet("+!e", "_Exit") ;Shift-Alt-E to Exit the script MsgBox(64, "Excel UDF: Events Example", "Hotkey to exit the script: 'Shift-Alt-E'!") ; Create application object and open a workbook Global $oExcel = _Excel_Open() Global $oWorkbook = _Excel_BookNew($oExcel) ObjEvent($oWorkbook, "Workbook_") While 1 Sleep(10) WEnd Exit Func Workbook_BeforeClose() MsgBox(0, "WorkbookBeforeClose", "Name: " & $oWorkbook.Name) _Excel_Close($oExcel) _Exit() EndFunc ;==>Workbook_BeforeClose Func _Exit() Exit EndFunc ;==>_Exit This example works for the workbook opened by this script. If the user opens and closes another workbook nothing will happen.

You can't, not with standard functionality of a list view . Only the item (first column) can be edited in place using $LVS_EDITLABELS. If you truly want it, you would need a workaround, like creating an input box when you dbl-click on a subitem. Here a simple example : #include <GUIConstants.au3> #include <GuiListView.au3> Opt("GUICloseOnESC", 0) Opt("MustDeclareVars", True) Global $hList, $idDummy Example() Func Example() Local $hMain = GUICreate("Example", 230, 170) Local $idList = GUICtrlCreateListView("Column 1|Column 2", 10, 10) GUICtrlCreateListViewItem("Item 1|Item 2", $idList) GUICtrlCreateListViewItem("Item 3|Item 4", $idList) $hList = GUICtrlGetHandle($idList) $idDummy = GUICtrlCreateDummy() GUIRegisterMsg($WM_NOTIFY, WM_NOTIFY) GUISetState() Local $iItem, $iSubItem, $aRect, $sData, $aPos = ControlGetPos($hMain, "", $idList) While True Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idDummy $iItem = _WinAPI_LoWord(GUICtrlRead($idDummy)) $iSubItem = _WinAPI_HiWord(GUICtrlRead($idDummy)) If $iSubItem = 0 Then ContinueLoop $aRect = _GUICtrlListView_GetSubItemRect($idList, $iItem, $iSubItem) $sData = GUICreateInput($hMain, _GUICtrlListView_GetItemText($idList, $iItem, $iSubItem), $aRect[0] + $aPos[0], $aRect[1] + $aPos[1], $aRect[2] - $aRect[0], $aRect[3] - $aRect[1]) If $sData Then _GUICtrlListView_SetItemText($idList, $iItem, $sData, $iSubItem) EndSwitch WEnd EndFunc ;==>Example Func WM_NOTIFY($hWnd, $iMsg, $wParam, $lParam) Local $tInfo = DllStructCreate($tagNMITEMACTIVATE, $lParam) If $tInfo.hWndFrom = $hList And $tInfo.Code = $NM_DBLCLK Then GUICtrlSendToDummy($idDummy, _WinAPI_MakeLong($tInfo.Index, $tInfo.SubItem)) Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY Func GUICreateInput($hWnd, $sText, $iLeft, $iTop, $iWidth, $iHeight) Local $hGUI = GUICreate("", $iWidth, $iHeight, $iLeft, $iTop + 1, $WS_POPUP, $WS_EX_MDICHILD, $hWnd) Local $idInput = GUICtrlCreateInput($sText, 0, 1, $iWidth, $iHeight - 1) Local $idOut = GUICtrlCreateDummy() GUISetState() GUISetState(@SW_DISABLE, $hWnd) Local $aAccel[2][2] = [["{ENTER}", $idInput], ["{ESC}", $idOut]], $sInput GUISetAccelerators($aAccel, $hGUI) While True Switch GUIGetMsg() Case $idInput $sInput = GUICtrlRead($idInput) ExitLoop Case $idOut ExitLoop EndSwitch WEnd GUIDelete($hGUI) GUISetState(@SW_ENABLE, $hWnd) GUISetState(@SW_RESTORE, $hWnd) Return $sInput EndFunc ;==>GUICreateInput