>>I'm not George, but I like using the native Event object for the OS via a couple of API calls:
>>
>>

DECLARE INTEGER CreateEvent IN WIN32API ;
>>   INTEGER lpEventAttributes, ;
>>   SHORT bManualReset, ;
>>   SHORT bInitialState, ;
>>   STRING @ lpName
>>DECLARE INTEGER GetLastError IN Win32API
>>DECLARE CloseHandle IN Win32API INTEGER hObject
>>nEh = CreateEvent(0,0,1, PROGRAM(0) + '.EVENT')
>>IF GetLastError() = 183 OR nEh = 0
>>   *  There's an instance running already (183) or the Event can't be defined
>>   *  So don't do it;  do release the handle, since it's harmless and should
>>   *  be done rather than relying on Windows to clean up after itself
>>   =CloseHandle(nEh)
>>   QUIT
>>ENDIF
>>
>>*  While shutting down, issue:
>>=CloseHandle(nEh)

>>
>>This has the advantage that it derives it's Event name from the executable, and if you do forget to issue a CloseHandle(), it still releases the Event object without bleeding, and the Event object completely disappears automagically when no remaining Event refs exist. CLOSE ALL will release the Event. You can use the Event for synchronizing several processes or thread using WaitForSingleObject() to wait on someone to 'raise' the event if you need some sort of event monitoring. Works under all OS versions I tested - not checked under Win95, but does work on Win98 and ME, as well as NT and 2K.
>>
>>You can use any name you want if linking to the app's initial program doesn't work for you - I chose that because it's easy to get right, and presumably you want to block other instances of the app you're starting.
>
>PMFJI,
>
>Ed, this is really an exciting chunk of code! Until now, I've always played the Window Title game. I've tested it and I've gone to MSDN to read about it and about WaitForSingleObject so I wouldn't be wasting your time.
>
>I'm not an API genius, but I'd love to understand this a bit more. I'm not sure I follow what's going on here.
>
>Are you registering a bogus event with Windows? The 1 makes it signalled , right? So, if I wanted to WaitForSingleObject, I'd wait to see the signalled state turn off? I saw SetEvent and ResetEvent for that. I guess the piece I'm missing is: What is this "event" thing that we're creating? Is it just like a flag? and Would I need to write a loop around WaitForSingleObject or is that the cool thing about it is that it sits there and "polls" the event?
>

I'm relying on the behavior of CreateEvent(), which states that attempting to create an event that already exists suceeds, and returns a handle to the existing Event, but returns a GetLastError value of 183 to indicate that the event is already defined. If the event has been defined, then soimeone has a handle to it already, so don't start this instance. I'm not using the signaled state at all. The event remains only as long as at least one valid event handle remains, so that it effectively acts as a self-reseting block with the little dribble of code above.

I can also use the same Event as an Event, the Initial State of 1 indicates that I start it signalled, so the next thing can proceed. If I wanted to block others, I'd call ResetEvent(). Here, you could synchronize several proceses through WaitForSingleObject/WaitForMultipleObjectEx/MsgWaitForMultipleObject relying on the event behavior, rather than the convenient behavior of CreateEvent().

IOW, two for the price of one. Single instance based on the CreateEvent() behavior, and synchronization if not running single instance and relying on one of the Wait mechanisms.