ProcessExist

[SmOke_N]

I have a Windows Title that changes all the time randomly, and I never know what it will be. But, the Process .exe is always the same.

I want to run a script, and if it already exist (It always will, because it's the .exe in the Processes), then to kill the new version opening.

Sort of like:

If WinExist("Window Title") Then
ProcessClose(That.exe)
Endif

This obviously isn't going to work:

If ProcessExist("That .exe") Then
ProcessClose("That .exe")
Endif

Anyone have any idea how I would close only the new .exe trying to start if it exists in the Processes already?

[LxP]

Could you please clarify what you're asking for us? I'm not too sure as yet why your ProcessExists() test wouldn't work.

After reading again:

I want to run a script, and if it already exist (It always will, because it's the .exe in the Processes), then to kill the new version opening.

Could this be done by checking for the existence of a script before doing anything and then launching it if needed? You don't appear to be working with an AutoIt script here because of the constant random title changing. Edited July 12, 2005 by LxP

[SmOke_N]

The application I'm starting is the Process.

If you use:

If ProcessExist("That .exe") Then
ProcessClose("That .exe")
Endif

It will always close the application you are trying to start whether it exist or not.

Sorry I wasn't more specific.

[LxP]

The application I'm starting is the Process.

If you use:

If ProcessExist("That .exe") Then
ProcessClose("That .exe")
Endif

It will always close the application you are trying to start whether it exist or not.

Is it possible to check for the existence of this application in memory before attempting to launch it?

[SmOke_N]

Blah!

Out of curiousity, is their anyway to change the "Class" of a compiled Autoit Script to something unique?

This would make it much easier perform my task, just incase someone has an AutoIt v3 GUI.

If it's suggested to Compile with another Compiler, can you refer me to a site that I can do this on?

But, obviously I would much rather just use the internal capabilities.

(P.S. I may start this in a different thread, since it has 2 implications for me)

[w0uter]

are you trying to do this? (taken from the manual)

14. How can I make sure only one copy of my script is run?

The easiest way is to rename the title of the hidden AutoIt window when your script first starts.  Then in the same script check for that window title existing - if it does then another copy of the script is running.

; Place at the top of your script

$g_szVersion = "My Script 1.1"

If WinExists($g_szVersion) Then Exit ; It's already running

AutoItWinSetTitle($g_szVersion)

; Rest of your script goes here

Back To Top

[SmOke_N]

No, because the user can change the title randomly as they wish to what they wish.

This works:

If UBound(ProcessList(@ScriptName)) > 2 then 
    MsgBox(16, "Error", "You can only have 1 copy of this application running at a time")
    Exit
EndIf

Thanks though, I had already tried that: I do read the help and search the forum for hours before posting.

But, I would still like to know the answer to:

Out of curiousity, is their anyway to change the "Class" of a compiled Autoit Script to something unique?

Edit: Forgot a "/" Edited July 12, 2005 by ronsrules

[LxP]

Just for my sanity can you please clarify what you're trying to do? Are you trying to launch an AutoIt script if it's not already in memory? Are you trying to launch something completely different? You have been quite vague as to what this process with its haywire title string actually is.

It appears to be an AutoIt script because you don't seem to want to check for it via its process filename, which would be understandable if it is in fact an AutoIt script. If it isn't then is multiple copies of it running at once a possibility?

I may or may not have asked this before but since you can't check for the process' existence after launching it (as this would always return true) can you check for the process' existence before attempting to launch it? (This would depend on the fact that there can't be more than one copy of the process in memory, as I said earlier.)

If we're dealing with an AutoIt script, you could always compile it and give it a unique filename; then you'd be able to check for its existence via that name.

[SmOke_N]

Just for my sanity can you please clarify what you're trying to do? Are you trying to launch an AutoIt script if it's not already in memory? Are you trying to launch something completely different? You have been quite vague as to what this process with its haywire title string actually is.

It appears to be an AutoIt script because you don't seem to want to check for it via its process filename, which would be understandable if it is in fact an AutoIt script. If it isn't then is multiple copies of it running at once a possibility?

I may or may not have asked this before but since you can't check for the process' existence after launching it (as this would always return true) can you check for the process' existence before attempting to launch it? (This would depend on the fact that there can't be more than one copy of the process in memory, as I said earlier.)

If we're dealing with an AutoIt script, you could always compile it and give it a unique filename; then you'd be able to check for its existence via that name.

<{POST_SNAPBACK}>

Hey LXP, your always quite helpful so I'll try to answer this as clarified as I can.

1. I have a GUI, that is being launched on multiple computers (compiled).

2. The users can change the .exe randomly so I never know what it is. (trying to obtain anonymity).

3. I had it at the top of my script to check if the ProcessExist("Original.exe") but since they can change it, I didn't know what to put in place of "Original.exe".

4. Because it was on multiple computers, I didn't know or 'think' for that matter if the memory thing would work being that there may be instances that they may have something in the memory that matched.

5. The Unique "Class" was I thought a good Idea, because they could always change the .exe but the class would stay the same.

All in all, I need(ed) something that could be dummy proof. Allow them to change the .exe name, and still find out if it was in processes. But, if they named it something like Notepad.exe, that they wouldn't freak when the program wouldn't open because it was already in the process list.

Hope this clears it up a bit and brings you more sanity.

[LxP]

Okay, this makes a lot more sense now. You have a compiled AutoIt script which can obviously have any filename, which means that you can't check for a process if you don't launch it initially via another script (and hence track its PID).

You can't check for a class name because as yet there is no way to customise this on a per-script basis.

At this point, if reprogramming and redeploying your compiled script is a possibility then two options seem quite good. You could reprogram your script to either write a registry entry signifying that the program is running, or write to a zero-sized file in a temporary location. Your script would then delete that entry/file on exiting.

Obviously if the system crashes then the entry/file remains and you have the problem that the registry/temporary folder reports that the program is running. You could overcome this by writing the location of the compiled script to the registry/file and then your other script can test if a program of that location is running.

ProcessExists() doesn't appear to let a coder check that a process in a specific directory is running, e.g. --

processExists("C:\Windows\Calc.exe")

but perhaps this is a good feature request.

Hope this clears it up a bit and brings you more sanity.

Thanks and sorry if I came across a bit rudely before -- it's never intentional! One problem with online communication is that if something isn't written carefully, it's sometimes possible to 'read between the lines' and pick up emotions that really aren't intentionally there. Edited July 13, 2005 by LxP

[MSLx Fanboy]

If ProcessExists(@ScriptName)?

[LxP]

Unfortunately in this situation we have one script checking for the existence of another, and so this wouldn't work.

[w0uter]

@LxP

what if they move the exe

@evryone who is interested

im working on a PID to Path func.

[Valik]

You'd think an operating system would have provisions for this sort of thing. Maybe you could find it using terms like "Synchronization Objects"?

[LxP]

what if they move the exe

<{POST_SNAPBACK}>

Ideally the compiled script would report its full path to the registry, and then the other script could read that full path and somehow determine from that if it were running. If ProcessExists() could accept a full path then that's how it could be done.

You'd think an operating system would have provisions for this sort of thing.  Maybe you could find it using terms like "Synchronization Objects"?

Mutexes! Of course! If you programmed your original script to create a 'mutex' on startup then you could check for this mutex within your other script. (The way I understand it, a program can create a 'mutex' which is some sort of string in the OS memory that will exist as long as the program is running. Other processes can ask the OS if such a string exists in memory. I know I'm technically far off but Windows programming is next semester.)

I personally have no idea how to implement this into a script but it's probably possible (for compiled scripts anyway) via the beta release's DLLCall() or maybe one of the ObjXXX() functions.

Edited July 13, 2005 by LxP

[SmOke_N]

What about something like this? Do you think this would work in my instance?

Global $Find_Exe = Find_Exe()

If UBound(ProcessList($Find_Exe)) > 2 then
   MsgBox(16, "Error", "You can only have 1 copy of this application running at a time")
   Exit
EndIf

Func Find_Exe()
   $search = FileFindFirstFile(@ProgramFilesDir & "\MyFile\*.exe")
   If $search = -1 Then
      MsgBox(0, "Error", "MyFile Folder is Missing or the .exe for MyFile is Missing")
      Exit
   EndIf
   While 1
      $Find_Exe = FileFindNextFile($search)
      If @error Then ExitLoop
      Return $Find_Exe
   WEnd
   FileClose($search)
EndFunc

Haven't tested it but, looks like it might.

[Valik]

I personally have no idea how to implement this into a script but it's probably possible (for compiled scripts anyway) via the beta release's DLLCall() or maybe one of the ObjXXX() functions.

One could always search.

[SmOke_N]

OMG, Valik has a new PIC!

[LxP]

Okay, so using an adaptation of Valik's Singleton() code, you could place this at the beginning of your compiled GUI script:

; set this variable to some unique value like what your GUI does
local $semaphore = "Ron's Compiled GUI Script"
dllCall("kernel32.dll", "int", "CreateSemaphore", "int", 0, "long", 1, "long", 1, "str", $semaphore)

My understanding is that this will create a semaphore of 'Ron's Compiled GUI Script' in memory whenever there is at least one copy of the GUI in memory. If you wanted to ensure that only one copy were ever to load then you could refer to Valik's mentioned thread.

In your script that checks for the GUI process, you would need a method of checking that that semaphore exists. I'm afraid I can't help there as I know squat about the Windows API but I believe that Valik could help out.

$guiRunning = dllCall(...)
if ($guiRunning = ...) then
    ; ...
endIf

[Valik]

The Singleton code demonstrates how to determine if the Semaphore exists. You simply try to create another instance and immediately check GetLastError() (API call) to see if it returns ERROR_ALREADY_EXISTS. All the logic necessary is demonstrated in the function.

The only thing that makes my code a "Singleton" is it calls Exit if the Semaphore exists already. The actual action taken is entirely up to the user. I choose to exit, hence it fits into the Singleton pattern since it will only allow one instance of itself to run.