autoitscript.com

Hello all, I have developed a code to use WinActivate to login to an application for validation/testing. If I RDP to the machine, the code executes successfully. However, if I use an interactive console session, it does not work. I initially thought the root cause was related to the screen resolution, but even after settings the resolution to 1920x1080, the issue still persists. I would greatly appreciate your help. Thank you in advance! -SK

Not an help request, just a reminder for programmers in most languages. The range of integers representable in a signed Int64 is [-9223372036854775808, 9223372036854775807], or hex [0x8000000000000000, 0x7FFFFFFFFFFFFFFF]. This is well known. But what is the range of integers continuously and exactly representable in a 64-bit real ? I happen to have found a bug in a program (not AutoIt) whose author didn't suspect this limitation of the range: It is [-9007199254740992, 9007199254740992], that is 3 orders of magnitude less than for signed Int64. Note that modern CPUs have the capacity to perform intermediate operations using 80-bit floats, but I/O always revert to 64-bit format unless extra caution is involved. Of course applications juggling with such huge values are rare, yet it's worth keeping this limitation in mind.

Hi everyone, I have a noob question: I have a fairly long piece of code, and I've simplified it to the bare essentials to illustrate the problem. When I click a button to trigger a function, I get a spinning hourglass icon in Windows. Strangely enough, the AutoIT GUI works perfectly fine, but I'm sure there must be a small mistake somewhere in the code. Thanks. #NoTrayIcon #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include $Gui = GUICreate( "GUI", 300, 200) $Button_Connectr = GUICtrlCreateButton("&Call Function", 20, 20, 200, 40) GUIStartGroup() GUISetState(@SW_SHOW) While 1 $msg = GUIGetMsg() If $msg = $GUI_EVENT_CLOSE then DriveMapDel("P:") Exit EndIf If $msg = $Button_Connectr then F_LWR() Sleep(5) WEnd Func F_LWR() GUISetCursor(15,1) EndFunc

Hello everybody What is the correct way to remove all keys at once in a Map declared as Local Static ? Because cycling through all the keys to remove them one by one isn't user friendly and not a good solution in case of a big Map. I found a way to do it, but maybe you know if there is a native instruction that does it better ? Please have a look at the following canvas, where a user drags one of the Tab controls inside the GUI to move it at a different place (they may be several Tab controls in the GUI as stated in the help file, function GUICtrlCreateTab) : A GUI can only hold a single tab control, but it is possible to create child GUIs each holding a tab control. Func WM_ENTERSIZEMOVE($hWnd, $iMsg, $wParam, $lParam) Switch $hWnd Case $g_hGUIMask If $g_sClassName = "SysTabControl32" Then _TabIsMoving($g_idControl, $WM_ENTERSIZEMOVE) EndIf Case ... ... EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_ENTERSIZEMOVE Func WM_MOVE($hWnd, $iMsg, $wParam, $lParam) Switch $hWnd Case $g_hGUIMask ... ; any control of the GUI just moved here (Tab control or other control), then : If $g_sClassName = "SysTabControl32" Then _TabIsMoving($g_idControl, $WM_MOVE) EndIf Case ... ... EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_MOVE Func WM_EXITSIZEMOVE($hWnd, $iMsg, $wParam, $lParam) Switch $hWnd Case $g_hGUIMask If $g_sClassName = "SysTabControl32" Then _TabIsMoving($g_idControl, $WM_EXITSIZEMOVE) EndIf Case ... ... EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_EXITSIZEMOVE Func _TabIsMov

Hello, I need to run an external program, read its stdout until there's nothing left to read, display whatever stdout + stderr finally contain, and end. For some reason, the following code outputs tons of repeats. I expected 1) each call to StdoutRead() to empty the buffer, and 2) no repeats. What am I doing wrong? Thank you. #include #include #include #include #include #include #include #include $sCMD = @ComSpec & " /c DIR" Local $line = "" Local $foo = Run($sCMD , "C:\", @SW_SHOW, BitOR($STDERR_CHILD, $STDOUT_CHILD)) While Not @error $line &= StdoutRead($foo) ConsoleWrite($line & @CRLF) WEnd ConsoleWrite("Final STDOUT read:" & $line & @CRLF) ConsoleWrite("Stderr Read:" & StderrRead($foo) & @CRLF) ;=> Tons of empty lines, followed by several repeats of the $sCMD command output, followed by a single occurence of "STDOUT read:".

I was looking for a simple function to quickly tell me whether the master volume is muted or not. Most of what I found was old stuff that no longer applies to current versions of Windows. Nothing I found was simple. So this is what I wrote: #include ; needed for _WinAPI_EnumProcessWindows function Switch IsMuted() Case 0 MsgBox(0, "Master Volume", "Not Muted") Case 1 MsgBox(0, "Master Volume", "Muted") Case Else MsgBox(0, "Master Volume", "Unable to determine Muted Status") EndSwitch Func IsMuted() ; Returns 1 if master volume is muted. ; Returns 0 if master volume is not muted. ; In case of a problem, will return -1 and will set @error to -1 also. Local Const $eUnmute = "unmute" ; magic word to look for in text of Volume Mixer window to determine if muted or not ; this word may be different in non-English Windows installs Local $iPID ; PID of SndVol.exe process Local $bCloseProcWhenDone ; First check to see if SndVol.exe is already running. ; If so, use it. If not start a hidden instance of SndVol.exe. $iPID = ProcessExists("SndVol.exe") If $iPID = 0 Then ; No existing process, need to run SndVol.exe. $iPID = Run(@SystemDir & "\SndVol.exe", "", @SW_HIDE) $bCloseProcWhenDone = True Else $bCloseProcWhenDone = False EndIf ; Target window of process will have no Title but will have Class of #32770. ; Text of target window will include the magic word ('unmute' in English) only if mute is on. ; Need to be able to see text on a hidden window Local $iPriorOpt = Opt("WinDetectHiddenT

Hi, I have software that initiates an analysis by clicking a blue button on an open window. I'm trying to automate the initiation using a clicker script that prompts me to enter how many times the script should click. It would be best if the script could find the button automatically since the window may move around and sometimes be in the background. The clicks need to occur approximately 3 minutes apart, as many times as the user enters. It's the blue "stop/play" button in the picture that needs to be clicked. So far I've only found a way to receive input via a GUI: #include #include #include Main() Func Main() $Form1 = GUICreate("Name", 251, 161, -1, -1, BitXOR($GUI_SS_DEFAULT_GUI, $WS_MINIMIZEBOX)) $label1 = GUICtrlCreateLabel("Whatever you want to write", 10, 10) $Input1 = GUICtrlCreateInput("", 24, 96, 201, 21, $ES_NUMBER) GUICtrlSetLimit(-1, 4) $Button1 = GUICtrlCreateButton("OK", 24, 128, 75, 25) $Button2 = GUICtrlCreateButton("Cancel", 152, 130, 75, 25) GUISetState(@SW_SHOW) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit Case $Button1 If StringLen(GUICtrlRead($Input1)) < 4 Then GUICtrlSetData($Input1, "") Else ConsoleWrite("Success" & @CRLF) EndIf EndSwitch WEnd Local $Counter = 0 While $Counter < $Input1 ; Perform mouse click ; Not sure how to do this ; Sleep for 3 minutes Sleep(60000 * 3) $Counter = $Counter + 1 WEnd EndFunc Thankful for any input : )

hi sorry for disturb I have a code that changes the Windows 11 right-click menu style back to Windows 10, then kills explorer and is supposed to relaunch it, but it doesn't relaunch it—it opens a folder instead. ; AutoIt - Gestione Menu Contestuale Windows 10/11 #include #include ; Crea la finestra $hGUI = GUICreate("Gestione Menu Contestuale", 380, 90, -1, -1, $WS_SYSMENU) $btnON = GUICtrlCreateButton("Tasto DX Win10 Style ON", 10, 20, 160, 50) $btnOFF = GUICtrlCreateButton("Tasto DX Win10 Style OFF", 200, 20, 160, 50) ; Aggiorna stato pulsanti UpdateButtons() GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE Exit Case $btnON ; Attiva stile Windows 10 RunWait(@ComSpec & ' /c reg add "HKCU\SOFTWARE\CLASSES\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /ve /f', "", @SW_HIDE) RestartExplorer() UpdateButtons() Case $btnOFF ; Ripristina stile Windows 11 RunWait(@ComSpec & ' /c reg delete "HKCU\SOFTWARE\CLASSES\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /f', "", @SW_HIDE) RestartExplorer() UpdateButtons() EndSwitch WEnd ; Funzione per verificare se lo stile Windows 10 &egrave; attivo Func CheckWin10Style() Return RegRead("HKCU\SOFTWARE\CLASSES\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32", "") <> "" EndFunc ; Funzione per aggiornare lo stato dei pulsanti Func UpdateButtons() If CheckWin10Style() Then GUICtrlSetState($btnON, $GUI_DISABLE) GUICtrlSetState($btnOFF, $GUI_ENABLE) Else GUICtrlSetState($btnON, $GUI_ENABLE) GUICtrlSetState($bt

I'm playing around with the DPI related functions for DPI Awareness Context from UEZ's _WinAPI_DPI.au3 UDF. I need to be able to get the DPI Awareness Context values and make decisions based on those returns. The part that I don't understand is that the values for these are: $DPI_AWARENESS_UNAWARE = 0 Global Const $DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE = $DPI_AWARENESS_UNAWARE - 3 Global Const $DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 = $DPI_AWARENESS_UNAWARE - 4 So my assumption is that I would get a return of -3 for PMv1 and -4 for PMv2. But instead, I am getting a return of 18 for PMv1 and 34 for PMv2. I assume that there must be a way to interpret this return to match the initial -3 or -3 that I thought were the values. If anyone can help me understand this better, I would greatly appreciate it. Here is the script that I am testing: #include ;https://learn.microsoft.com/en-us/windows/win32/api/windef/ne-windef-dpi_awareness Global Enum $DPI_AWARENESS_INVALID = -1, $DPI_AWARENESS_UNAWARE = 0, $DPI_AWARENESS_SYSTEM_AWARE = 1, $DPI_AWARENESS_PER_MONITOR_AWARE = 2 ;https://learn.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context Global Const $DPI_AWARENESS_CONTEXT_UNAWARE = $DPI_AWARENESS_UNAWARE - 1 Global Const $DPI_AWARENESS_CONTEXT_SYSTEM_AWARE = $DPI_AWARENESS_UNAWARE - 2 Global Const $DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE = $DPI_AWARENESS_UNAWARE - 3 Global Const $DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 = $DPI_AWARENESS_UNAWARE - 4 Global Const $DPI_

Per-Monitor v2 Scaling UDF This is still quite early stages of this UDF, so I am still trying to get everything organized. Please feel free to share any feedback and feel free to contribute as well if you would like. How To Use: At the top of your script, you need to include the PMv2 UDF file and initialize the Per-Monitor V2 DPI scaling (prior to creating your GUI): #include "PMv2.au3" _PM_Init() After creating all of your controls, but just before showing your GUI with GUISetState, you need to apply the initial scaling: _PM_Scale($hGUI) GUISetState(@SW_SHOW, $hGUI) Changelog: Spoiler PMv2 2026.08.09: Fixed an issue with font scaling for SysHeader32 control of a ListView Cleaned up code and structured more like a proper UDF Adding some of the functions created by ioa747 which provide more fallback mechanisms PMv2 2026.08.10: Added functions __PM_Cleanup() and __PM_Free() from ioa747 to assist with font cleanup Removed decimal places from control coordinates using Floor() Determine if GUI was centered initially and ensure that GUI is centered after scaling (first launch only) PMv2 2026.08.12: Added menubar and Statusbar control to Example test scaling engine Added current DPI, scaling percentage and DPI awareness context to Statusbar Statusbar updates part text on DPI changes Implemented method to have two GUIRegisterMsg for WM_DPICHANGED messages This allows user script (Statusbar in case of Example) to get updates on WM_DPICHANGED changes as well This is achieved by registe

What is the status of the SciTE > VSCode development environment migration? To put it another way, have all SciTE functionalities (including those from DynamicLUA) been ported to VSCode add-ons? What additional benefits does VSCode offer compared to SciTE + DynamicLUA?

First off, Thank you for hard work on the WebDriver UDF. I would like to comment on the latest version. I love Autoit and all that have contributed. The Function _WD_ElementAction specifically where it was previously used to Send Keyboard keys for example "Enter". In previous versions a keyboard key like Enter ( "\uE007") could be sent as _WD_ElementAction($sSession,$sElement,"value","\uE007") This would send a keyboard Enter to $sElement. This works Great. I do not understand how to do this, _WD_Action($sSession,"actions","\uE007") does Not work. I realize that I may have to create a Json object to replicate this. My Solution for now will be to change wd_Core and remove "__WD_EscapeString($sOption)" and replace it with "$sOption" I always reference back to my "idea of Autoit" and that is to "Simplify windows". So if WebDriver is to be "W3C" compliant, I would hope that an additional function / option would be created to handle Keyboard Keys. Here is an Example of what I am commenting on; ===================================================================================================== Native Autoit Solution; Local $hWD=Winactivate("Autoit") WinWaitActive($hWD,3) Send("{ENTER}") Old WebDriver Solution; _WD_ElementAction($sSession,_WD_FindElement($sSession,"xpath","//*[@id="elSearchField"]"),"value","\uE007") New WebDriver Solution; Local $sAction = '{"actions":[{"type": "key", "id": "keyboard_1", "actions": [{"type": "keyDown", "value": "\uE009"}, ' & _ '{"type": "keyDown"