AntS

@NineNoted. Thanks. There's one question that needs to be asked, so I may as well ask it... Is there any particular benefit to using _Singleton() to check for a previous instance over ProcessList() (or WinExists())?

Aha! Now, it makes sense. When the second instance is run, _Singleton() doesn't create a second mutex object, but it does recognise the existence of first. The object is lost when the first process is closed. Thank you very much for the explanation, Nine, and for the modified code. Thank you, argumentum, for the additional code and pointers. 🙂

Almost as soon as I hit Submit Reply, I realised... it's not necessary to use _Singleton() at all. If ProcessList() returns a count of 2 or more for the given .exe name, we know there's at least one previous instance. The contents of the process list can then be used as normal to identify and close the unwanted processes. The code below succesfully allows you to chain process closures. #include <Misc.au3> Local $aProcessList Local $iPID Local $i, $iCount Local $sMsg ;get list of processes with same .exe name $aProcessList = ProcessList(@ScriptName) $iCount = $aProcessList[0][0] ;close any previous instances If $iCount >= 2 then MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", "At least one previous instance found.") $i = 1 While $i <= $iCount ;get process ID of i-th process $iPID = $aProcessList[$i][1] If $iPID <> @AutoItPID then ;close process MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", "Attempting to close process (ID " & $iPID & ").") ProcessClose($iPID) ;check whether process closed Sleep(1000) If ProcessExists($iPID) = 0 Then $sMsg = "Process (ID " & $iPID & ") no longer running." Else $sMsg = "Unsuccessful: process (ID " & $iPID & ") still running!" EndIf MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", $sMsg) EndIf $i = $i + 1 Wend EndIf ;perform script's task Sleep(60000)

Thanks, argumentum.  If there were something in ProcessExists() that meant it always returned the ID of a process other than its own then I could see how it'd make sense to use it.  Below is an alternative, condensed script that uses ProcessList() to deal with a previous instance. It attempts to close all matching processes other than its own.  #include <Misc.au3> Local $aProcessList Local $iPID Local $i, $iCount Local $sMsg ;close any previous instances If _Singleton("43832176", 1) = 0 then ;1 - do not exit script MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", "At least one previous instance found.") ;get list of processes with same .exe name $aProcessList = ProcessList(@ScriptName) $iCount = $aProcessList[0][0] $i = 1 While $i <= $iCount ;get process ID of i-th process $iPID = $aProcessList[$i][1] If $iPID <> @AutoItPID then ;close process MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", "Attempting to close process (ID " & $iPID & ").") ProcessClose($iPID) ;check whether process closed Sleep(1000) If ProcessExists($iPID) = 0 Then $sMsg = "Process (ID " & $iPID & ") no longer running." Else $sMsg = "Unsuccessful: process (ID " & $iPID & ") still running!" EndIf MsgBox ($MB_SYSTEMMODAL, "Example Script (ID " & @AutoItPID & ")", $sMsg) EndIf $i = $i + 1 Wend EndIf ;perform script's task Sleep(60000) However, I'm encountering some strange behaviour. If the .exe is run afresh, it does so correctly as a "singleton". If a second instance of the .exe is run, it correctly identifies and closes the first process. However, when a third instance is run (after the first has closed), it does not close the second process. It doesn't even flag its existence. The code should allow you to "chain" process closures. Do you have any idea what's happening? I'm wondering if it's something to do with (the implementation of) _Singleton().

Late question here... Apologies. In this line: $pid = ProcessExists(@ScriptName) ... how do we know that ProcessExists() is returning the process ID of the previous instance and not the current one? 🤔

Thanks for reminding me, Luke94. Yes. Tried it. Have also tried using _WinAPI_SetWindowPos() with $HWND_TOP for the $hAfter parameter to bring the dialog box to the top of the z-order. The calls to WinActivate(), ControlFocus() and _WinAPI_SetWindowPos(), as well as to ControlClick(), all return True (i.e. success), but don't produce the desired effect.

Help! The mouse clicks I'm sending to a control on a dialog box produce no response. The dialog box in question handles advanced display properties. The tab page my script interacts with is created by Trident Microsystems. It allows the user to enhance or attenuate the screen's RGB values. (See image.) My script automates the process of changing these in order to adjust the screen's hue or, when the red, green and blue values are all the same, the brightness. Producing a script to change the brightness has been quite straightforward. I use ControlClick() to send a mouse click to one of the trackbars on the right of the tab page. By default, they're linked and so move as one. The difficulty I'm having however is in automating the process when the desired red, green and blue values aren't the same as each other. Ordinarily, there are three ways of doing this: (1) clear the Link check box to unlink the three trackbars then either click on each trackbar or drag their sliders, (2) clear the Link tick-box then for each colour, click on the corresponding trackbar slider (to select it) then click on a point on the graph, and (3) click on the Load button to open an Open dialog box and load a preset (stored as a .gam file). However, when ControlClick() is used to clear the Link check box or to push the Load button, nothing happens. Making the dialog box the active window makes no difference. The AutoIt Window Info tool indicates that the Reload a Bitmap, Save, Load and Reset buttons, the Link check box and the graph are all the same control. (See other images.) In fact, it there are only four controls on the page: the tab page, which is an instance of a SysTabControl32 class, and the three trackbars, each of which is an instance of the TridentTrackBar class. (Am unsure whether the SysTabControl32 class is a Windows or third-party control.) What's the solution? Note that the MouseClick() function—as opposed to ControlClick()—does work, but having AutoIt commandeer the screen pointer isn't an acceptable solution. For the sake of completeness, here's the relevant code fragment for the Link check box. ;unlink trackbars WinActivate("(Multiple Monitors)") ControlClick("(Multiple Monitors)", "", 12320, "left", 1, 211, 252)