Leaderboard

wow, I see it too on my side. Have not used this in a while. I'd have to "get into it" but don't have the time to investigate. At least it has the file you were trying to get. Maybe is just the servers. I'll try a new server from mLipok's list use this url: http://timestamp.digicert.com/scripts/timestamp.dll I recompiled with the above replacing the old one and it worked

WinClose() uses the CLASS in the help file. Hey, welcome to the forum @CalebG ok, I see it now. I've pass it along.

@Acanis As you've found out, you can't have multiple instances of Chrome using the same user profile. Not sure why you are encountering the cache issue. Perhaps you could provide a brief example so that we can observe what you are attempting to do. You can attach to an existing Chrome instance, but only if it was started with the --remote-debugging-port commandline option. See below for example -- #include "wd_core.au3" Local $sDesiredCapabilities, $sSession ShellExecute("chrome.exe", "--remote-debugging-port=9222") SetupChrome() _WD_Startup() $sSession = _WD_CreateSession($sDesiredCapabilities) _WD_Navigate($sSession, "http://yahoo.com") Func SetupChrome() _WD_Option('Driver', 'chromedriver.exe') _WD_Option('Port', 9515) _WD_Option('DriverParams', '--verbose --log-path="' & @ScriptDir & '\chrome.log"') $sDesiredCapabilities = '{"capabilities": {"alwaysMatch": {"goog:chromeOptions": {"debuggerAddress": "localhost:9222"}}}}' EndFunc

its dism /get-wiminfo -Online

@Acanis 1. This has been already been covered in a previous generation of this thread. Try searching the forum for "rect" 1a. Not sure off hand. Let us know if you figure out a way. 😉 2. See FAQ #3 in the wiki

The issue has already been addressed here.

yes. the problem is that I don’t do homework, not my own and certainly not someone else’s. and this is some form of homework, or test, with a rigid and arbitrary requirement. why? because what you are asking for is, IMO, not something that solves a problem in the real world. so let’s say there is a word file that exists with 3 words: cat dog tree and a sentence file with 6 sentences: 1. The cat ate the dog. 2. The dog ate the tree. 3. The tree ate the dog. 4. The dog ate the cat. 5. The cat ate the tree. 6. The tree ate the cat. you would say the result file should be sentences 1,4,5,2,3 and yet if I were to *ADD* the word ate to the word file: ate cat dog tree the result file would actually be *REDUCED*: 1,2,3 furthermore, changing the order in the word file changes the results file, - and all this without even an indication which word caused the match to appear - or disappear? Nope, nobody is solving a real world problem like this. Prove me wrong, what is the use case?

My post was not intended as 'bashing' (if your comment aimed at me). I have no reason to do so. I just wanted to additionally point out, that the help provides a good description of the respective parameter. Perhaps @faustf has overlooked this issue .

I would agree, except Musashi also tried to help explain why faustf was wrong

I know I shouldn't add to the fire In my universe, once corrected, one stands corrected. More corrections does not correct more. It just feels like a useless bashing.

It’s an i9-10900K. I put off getting a new box for years because the CPUs didn’t seem to making any dramatic progress, at least as far as single-threaded tasks are concerned (go autoit!). Then @Earthshine convinced me

To save CPU, maybe: If Random(0,9,1) Then Exit ; program

It would certainly help if you could fully explain the criterion you use to decide if a given subset satisfies your requirements. You probably could use that to constrain the generation to directly yield only subsets which you regard as "satisfactory". Also AutoIt is probably not the best tool for such heavy lifting. For instance, 50C6 (with the items being integers) takes about one second to compute using Mathematica. Of course the full result (a huge list) would take very long to display, something I've omitted here: In[1]:= Timing[Subsets[Table[x, {x, 1, 50}], {6}];] Out[1]= {1.01563, Null} You're likely to get the same kind of speed with similar (and much cheaper) CAS (computational algebra system = mathematical software) like SageMath, Magma, GAP, PARI/GP and others freewares. Payware CASes are Maple, Mathematica, and many more. See https://en.wikipedia.org/wiki/Category:Computer_algebra_systems

Ok, here my latest test (under 25 secs) for a 50C6. Script 1 (need to be compiled into PrintCombi.exe) : #include <Constants.au3> Const $iN = 6, $iR = 50 Local $aArray[$iR] For $i = 0 To UBound($aArray) - 1 $aArray[$i] = $i + 1 Next Local $iStart = $CmdLine[1], $iEnd = $CmdLine[2] ;Local $iStart = 1, $iEnd = 44 Local $sOutName = $iStart & ".txt" Local $hOutFile = FileOpen($sOutName, $FO_OVERWRITE) Local $iNum = 0 Local $hTimer = TimerInit(), $sResult For $i = $iStart - 1 To $iEnd - 1 $sResult = "" For $j = $i + 1 To $iR - $iN + 1 For $k = $j + 1 To $iR - $iN + 2 For $l = $k + 1 To $iR - $iN + 3 For $m = $l + 1 To $iR - $iN + 4 For $n = $m + 1 To $iR - $iN + 5 ; For $o = $n + 1 To $iR - $iN + 6 ; For $p = $o + 1 To $iR - $iN + 7 $iNum += 1 $sResult &= $aArray[$i] & "," & $aArray[$j] & "," & $aArray[$k] & "," & $aArray[$l] & "," & $aArray[$m] & "," & $aArray[$n] & @CRLF ; Next ; Next Next Next Next Next Next FileWrite($hOutFile, $sResult) Next FileClose($hOutFile) ; MsgBox ($MB_SYSTEMMODAL, $iStart, TimerDiff($hTimer) & "/" & $iNum) ; to check which process finishes when Script 2 (Main.au3) #include <Constants.au3> Local $aPID[4] $aPID[0] = Run("PrintCombi.exe 1 2") $aPID[1] = Run("PrintCombi.exe 3 5") $aPID[2] = Run("PrintCombi.exe 7 10") $aPID[3] = Run("PrintCombi.exe 11 44") Local $hTimer = TimerInit() While True Sleep (500) For $i = 0 to 3 If ProcessExists($aPID[$i]) Then ContinueLoop 2 Next ExitLoop WEnd MsgBox ($MB_SYSTEMMODAL, "Over All", TimerDiff($hTimer)) I removed 2 loops in PrintCombi.au3 since it is now a C6. You can add more run in main if you got more processors (I got 4 on this machine). All left to do is run a Copy 1.txt+3.txt+7.txt+11.txt All.txt in DOS console. Or you could include it the main script if you wish to.

Just made a test on 50C6. I was able to create all combi and save it to file in about 75 secs. But I am looking in a faster way...

FordFinest, We have some issues with a few of the commands in the GuiTreeView UDF under Windows 10 64 bit. I had temporarily forgotten that in your previous post about the same subject a month ago. Sorry. The problem is obvious if you try the example of _GUICtrlTreeView_ClickItem in the help file under Windows 10 64 bit. The _GUICtrlTreeView_ClickItem command (here a double click) simply does not work. Make a copy of the example. Add the two functions here to the code and replace _GUICtrlTreeView_ClickItem with _GUICtrlTreeView_ClickItem64. Func _GUICtrlTreeView_ClickItem64($hWnd, $hItem, $sButton = "left", $bMove = False, $iClicks = 1, $iSpeed = 0) If Not IsHWnd($hWnd) Then $hWnd = GUICtrlGetHandle($hWnd) Local $tRECT = _GUICtrlTreeView_DisplayRectEx64($hWnd, $hItem, True) If @error Then Return SetError(@error, @error, 0) ; Always click on the left-most portion of the control, not the center. A ; very wide control may be off-screen which means clicking on it's center ; will click outside the window. Local $tPoint = _WinAPI_PointFromRect($tRECT, False) _WinAPI_ClientToScreen($hWnd, $tPoint) Local $iX, $iY _WinAPI_GetXYFromPoint($tPoint, $iX, $iY) Local $iMode = Opt("MouseCoordMode", 1) If Not $bMove Then Local $aPos = MouseGetPos() _WinAPI_ShowCursor(False) MouseClick($sButton, $iX, $iY, $iClicks, $iSpeed) MouseMove($aPos[0], $aPos[1], 0) _WinAPI_ShowCursor(True) Else MouseClick($sButton, $iX, $iY, $iClicks, $iSpeed) EndIf Opt("MouseCoordMode", $iMode) Return 1 EndFunc ;==>_GUICtrlTreeView_ClickItem Func _GUICtrlTreeView_DisplayRectEx64($hWnd, $hItem, $bTextOnly = False) Local $tRECT = DllStructCreate($tagRECT) Local $iRet If IsHWnd($hWnd) Then ; RECT is expected to point to the item in its first member. ;DllStructSetData($tRECT, "Left", $hItem) $iRet = @AutoItX64 ? DllStructSetData( DllStructCreate( "ptr", DllStructGetPtr( $tRect ) ), 1, $hItem ) _ : DllStructSetData( $tRect, "Left", $hItem ) If _WinAPI_InProcess($hWnd, $__g_hTVLastWnd) Then $iRet = _SendMessage($hWnd, $TVM_GETITEMRECT, $bTextOnly, $tRECT, 0, "wparam", "struct*") Else Local $iRect = DllStructGetSize($tRECT) Local $tMemMap Local $pMemory = _MemInit($hWnd, $iRect, $tMemMap) _MemWrite($tMemMap, $tRECT) $iRet = _SendMessage($hWnd, $TVM_GETITEMRECT, $bTextOnly, $pMemory, 0, "wparam", "ptr") _MemRead($tMemMap, $pMemory, $tRECT, $iRect) _MemFree($tMemMap) EndIf Else If Not IsHWnd($hItem) Then $hItem = _GUICtrlTreeView_GetItemHandle($hWnd, $hItem) ; RECT is expected to point to the item in its first member. DllStructSetData($tRECT, "Left", $hItem) $iRet = GUICtrlSendMsg($hWnd, $TVM_GETITEMRECT, $bTextOnly, DllStructGetPtr($tRECT)) EndIf ; On failure ensure Left is set to 0 and not the item handle. If Not $iRet Then DllStructSetData($tRECT, "Left", 0) Return SetError($iRet = 0, $iRet, $tRECT) EndFunc ;==>_GUICtrlTreeView_DisplayRectEx You haven't shown much code, but I think the two functions will solve your problem. If the code doesn't help then add a new post. The problem can certainly be solved. For one reason or another, Microsoft has stopped supporting the focused state of a treeview item. However, the dotted focus rectangle is still displayed. This is not an AutoIt problem.

This function rewrite whole content of given file by defined (implicitly 0x0) character and finally delete it, it's called as secure deleting. This should be VERY fast!! Just note that there is no error checking inside FileWipe() Maybe I will post later also version with error checking. You can comment line FileDelete($sFileName) to see how it's rewritten before deletion. EDIT: There can be problems with too big files (>2GB or > amount of RAM) see post #8 by Kafu #include <WinAPI.au3> ; prepare testing file FileDelete('1.txt') FileWrite('1.txt','123abc') FileWipe('1.txt') Func FileWipe($sFileName, $nByte = 0x0) If Not FileExists($sFileName) Then Return $iSize = FileGetSize($sFileName) $hFile = _WinAPI_CreateFile($sFileName, 2, 6) $hMapping = _WinAPI_CreateFileMapping($hFile) $pAddress = _WinAPI_MapViewOfFile($hMapping) MemSet($pAddress, $nByte, $iSize) _WinAPI_UnmapViewOfFile($pAddress) _WinAPI_CloseHandle($hMapping) _WinAPI_CloseHandle($hFile) FileDelete($sFileName) EndFunc Func MemSet($pDest, $nChar, $nCount) DllCall("msvcrt.dll", "ptr:cdecl", "memset", "ptr", $pDest, "int", $nChar, "int", $nCount) If @error Then Return SetError(1,0,False) Return True EndFunc ; from WinAPIEx - just simplified for this purpose Func _WinAPI_CreateFileMapping($hFile) Local $Ret = DllCall('kernel32.dll', 'ptr', 'CreateFileMappingW', 'ptr', $hFile, 'ptr', 0, 'dword', 0x4, 'dword', 0, 'dword', 0, 'ptr', 0) If (@error) Or (Not $Ret[0]) Then Return SetError(1, 0, 0) Return $Ret[0] EndFunc Func _WinAPI_MapViewOfFile($hMapping) Local $Ret = DllCall('kernel32.dll', 'ptr', 'MapViewOfFile', 'ptr', $hMapping, 'dword', 0x6, 'dword', 0, 'dword', 0, 'dword', 0) If (@error) Or (Not $Ret[0]) Then Return SetError(1, 0, 0) Return $Ret[0] EndFunc Func _WinAPI_UnmapViewOfFile($pAddress) DllCall('kernel32.dll', 'int', 'UnmapViewOfFile', 'ptr', $pAddress) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Here is my first test version without memory mapped files: Func FileWipe($sFileName, $nByte = 0x0) If Not FileExists($sFileName) Then Return $iSize = FileGetSize($sFileName) $tBuffer = DLLStructCreate("byte[" & $iSize & "]") MemSet(DLLStructGetPtr($tBuffer), $nByte, $iSize) $hFile = _WinAPI_CreateFile($sFileName, 2, 6) _WinAPI_WriteFile($hFile, DLLStructGetPtr($tBuffer), $iSize, $iSize) _WinAPI_CloseHandle($hFile) FileDelete($sFileName) EndFunc

After further deliberation, I find I should probably elaborate on my previous LOVE post. Is AutoIt perfect? In a technical sense, NO. In an objective sense, YES .... but with qualifiers. By objective, we are talking RELATIONSHIP. Just like any relationship, the partnership you have with AutoIt, is critical. Early on, your relationship can turn to love, and indeed for many, including myself, this happened with AutoIt. Many then later fall out of love with AutoIt, but not so myself and many others. As with any relationship that turns to love, there is a certain blindness in the early stages. That blindness can lead you to believe, that there is only PROS and no CONS. Obviously you eventually drift away from that stance with growth and gradually awakening of understanding. So, just like any worthwhile relationship over time, where you accept faults, and perhaps feel more endeared because of them, you can develop a different sense of perfection, that is not based on the object being perfect, but rather the overall potential you aspire to or have gained. In that regard, AutoIt is perfect to me ... and many others. Can that perfection be improved? Objectively, YES. Technically, NO. The brilliance about AutoIt though, is that you can achieve a relative sense of it being perfect, which is unlike many other languages out there ... most I deem.

Allow2010, I use hidden text rather then _Singleton and do something like this: ; When creating the GUI ; Create hidden label to identify App main window from any other App windows GUICtrlCreateLabel("App-Name Running", 200, 200, 15, 15) ; Then when the scrit first runs it checks if there is an existing instance ; Window could be hidden Local $iOldOpt = Opt("WinDetectHiddenText", 1) ; Show existing instance If WinExists("", "App_Name Running") Then WinSetState("", "App_Name Running", @SW_SHOW) WinSetOnTop("", "App_Name Running", 1) WinSetOnTop("", "App_Name Running", 0) Exit EndIf Opt("WinDetectHiddenText", $iOldOpt)Note the use of WinSetState and not GUISetState to show the GUI - this means that you need to use the same command when you hide/show your GUI internally or the code will not work. M23

Maybe you need to go into the shade and treat your sunstroke as this is a totally ridiculous post with all these quotes from the past and the quoted questions & Text & Formating... * click * Jos