ProcessExist

[SmOke_N]

Am I to understand that Even if the "Window Title" changes, and or the executible name changes, that the the "Semaphore" will call to memory the original instance, and still not allow it to run a duplicate copy in future calls.

See, I want to make sure, because my example above works well for me. But, my program has the option to change the window name "Ron's GUI" to "Goony Goo Goo GUI" if the user so wish, and they can change the Rons.exe to GoonyGooGoo.exe if they want.

Looking at the examples, (and trying to understand them), it looks like the $SEMAPHORE is hard coded to a specific window title. This would not work for me.

Of course, I'm sure I'm totally misunderstanding the above, and one of you will KINDLY tell me.

Edited July 14, 2005 by ronsrules

[LxP]

Valik, how would we go about determining the existence of a semaphore without trying to create it first? The problem with the above approach is that it can only be used by the script 'holding' the semaphore, i.e. the code cannot be used by some outside process to check for this process' existence.

[LxP]

Am I to understand that Even if the "Window Title" changes, and or the executible name changes, that the the "Semaphore" will call to memory the original instance, and still not allow it to run a duplicate copy in future calls.

<{POST_SNAPBACK}>

That's correct, although if you wanted to enable multiple instances (and you can if you want) then the semaphore would only act as indication that 'one or more of the GUIs are running'.

[Valik]

Valik, how would we go about determining the existence of a semaphore without trying to create it first?

OpenSemaphore?

The problem with the above approach is that it can only be used by the script 'holding' the semaphore, i.e. the code cannot be used by some outside process to check for this process' existence.

I'm afraid unless you were making an incorrect assumption about how a Semaphore works, I don't know what you're talking about with that statement. A Semaphore is a global object in Windows. All processes can choose to see it provided they know about it (Meaning, they know the name of it so can use Open/Create-Semaphore on it). Nothing is "holding" it, we're not using any of the wait/signal functions.

And if all else fails: read the documentation I linked to. This is pretty basic stuff here. Things get much more fun when you attempt to actually synchronize things instead of just use a Semaphore as a global "property" for a process.

[LxP]

Look out -- I think we're close to a solution now. Here's the situation as I see it and I hope it's correct:

• GUI Script is a compiled AutoIt script that presents a GUI. It should only ever be present once in memory (is that right Ron?) and it can have any title or EXE path.

• Checker Script is another AutoIt script that wants to launch GUI Script only if GUI Script is not already running. It cannot check for GUI Script's presence via a process name or via a title because they are variable. It cannot check for a class name since class names are a constant in any AutoIt script.

• GUI Script can be recompiled to create a semaphore at startup, which is some sort of string that can be placed in Windows' memory space and will hang around for as long as GUI Script resides in memory. When starting up it would try to create this semaphore, which will fail if such a semaphore already exists (which would signify a GUI Script already running) and would then quit. This would ensure that only one GUI Script ever runs at one time.

• Checker Script can now just attempt to launch GUI Script which will automatically ensure only one copy in memory.

This all hangs on the assumption that GUI Script only ever wants to be run once at one time. Being a GUI application, this is quite likely. If GUI Script wants to run alongside other copies of itself, then that is also possible but it would require another strategy.

Is this all correct?

Looking at the examples, (and trying to understand them), it looks like the  $SEMAPHORE is hard coded to a specific window title.  This would not work for me.

Think of $semaphore as a title of a hidden window that your GUI script could create (which isn't what happens). What would you title your GUI script if users couldn't rename its title bar? That's the perfect entry for $semaphore.

[SmOke_N]

Look out -- I think we're close to a solution now. Here's the situation as I see it and I hope it's correct:

• GUI Script is a compiled AutoIt script that presents a GUI. It should only ever be present once in memory (is that right Ron?) and it can have any title or EXE path.

• Checker Script is another AutoIt script that wants to launch GUI Script only if GUI Script is not already running. It cannot check for GUI Script's presence via a process name or via a title because they are variable. It cannot check for a class name since class names are a constant in any AutoIt script.

• GUI Script can be recompiled to create a semaphore at startup, which is some sort of string that can be placed in Windows' memory space and will hang around for as long as GUI Script resides in memory. When starting up it would try to create this semaphore, which will fail if such a semaphore already exists (which would signify a GUI Script already running) and would then quit. This would ensure that only one GUI Script ever runs at one time.

• Checker Script can now just attempt to launch GUI Script which will automatically ensure only one copy in memory.

This all hangs on the assumption that GUI Script only ever wants to be run once at one time. Being a GUI application, this is quite likely. If GUI Script wants to run alongside other copies of itself, then that is also possible but it would require another strategy.

Is this all correct?

Think of $semaphore as a title of a hidden window that your GUI script could create (which isn't what happens). What would you title your GUI script if users couldn't rename its title bar? That's the perfect entry for $semaphore.

<{POST_SNAPBACK}>

I'm trying to follow you 2.

At top of Script:

Singleton("Ron's GUI")


Func Singleton($semaphore)
    Local $ERROR_ALREADY_EXISTS = 183
    DllCall("kernel32.dll", "int", "CreateSemaphore", "int", 0, "long", 1, "long", 1, "str", $semaphore)
    Local $lastError = DllCall("kernel32.dll", "int", "GetLastError")
    If $lastError[0] = $ERROR_ALREADY_EXISTS Then Exit -1
    EndFunc; Singleton()

This works!!

But, I wll take my flamming now because I need to know for my own sanity now, why the idea I came up w/ sucks. I understand that "Valiks" Semaphore suggestion is a true fix to my problem, but what was wrong with this?:

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

Seriously "Valik" & "LxP", I need to know for my own peace of mind.

Edit:

Had I known of the semaphore before hand obviously I would of chosen that route, but other than the fact that the "MyFile" may be moved or changed, is there a flaw in the logic I took to solve my issue?

Edited July 14, 2005 by ronsrules

[LxP]

Sorry Ron; I meant to discuss your code this morning.

Your code doesn't suck -- without trying it, it definitely looks like it would do the job but it relies on a few conditions; firstly that your GUI script resides in a particular folder and secondly that it is the only executable within that folder. If a user has control of the script's EXE name then they may also feel that they can place other EXEs within that folder (and they probably should be able to do so without affecting functionality of your script, which it would).

You would need to change the If...EndIf() block slightly because in its current form ('if there are more than 2 processes of this name running then...') it will allow two copies of the script to run. (Edit: ignore all that. I just reread the ProcessList() rules.)

The semaphore solution will basically lift any such restrictions and as an added bonus, it requires less code!

Edited July 14, 2005 by LxP

[SmOke_N]

LOL, yes, I revamped mine w/ an edit, we posted seconds apart.