[fpc-pascal] File Association and opening with already running app

[Dennis]

In windows, you can create Mutex. That's how I ensure no other instance 
of the same program is running.

YourIDString is a string that you use to uniquely id your program instance .


   if OpenMutex(MUTEX_ALL_ACCESS, False, PChar(YourIDString)) = 0 then begin
     // First one - the mutex didn't exist, so create it.
     Result := CreateMutex(nil, False, PChar(YourIDString));
     MutexList.Add(pointer(Result));
   end else begin
     raise Exception.Create('The same program has been running already');
   end;


Make sure your free all mutex in the finalization of your unit or program

procedure FreeAllMutexes;
var
   M       : THandle;
   i       : integer;
begin
   for i := 0 to MutexList.Count - 1 do begin
     M := THandle(MutexList[i]);
     if M <> 0 then begin
       if not CloseHandle(M) then
         raise Exception.Create('Failed to release mutex:' + IntToStr(M));
       MutexList[i] := nil;
     end;
   end;
end;



Mark Morgan Lloyd wrote:
> Graeme Geldenhuys wrote:
>> On 2013-04-04 10:45, Mark Morgan Lloyd wrote:
>>> So far I've had no success porting that to Windows using named pipes,
>>
>> Ah, thanks for the idea. SimpleIPC should be able to do the trick -
>> similar to how apps communicate to a DebugServer (using dbugintf and
>> SimpleIPC units).
>>
>> First instance will search for a known IPC server, if none exist, start
>> the Simple IPC server. Second instance will first see if a existing IPC
>> server exists, and if so, send the open command to it, then quit.
>
> Yes, I agree. But my preference is to put the socket/pipe in the 
> user's home directory (i.e. rather than /tmp which is where it's 
> usually put), to name it including the PID to make it easily 
> trackable, and to use some combination of the original project name, 
> the final executable name (and possibly something from a .ini file) so 
> that it's possible to handle multiple instances.
>
> I suggest also adding status commands etc., i.e. so that you can query 
> whether a server's running, what its build is and so on. The way I did 
> it wasn't very good for that: it really needs bidirectional 
> communications (e.g. so that you can get the running copy's version 
> rather than just a version number from the binary you've just 
> executed) which isn't something I designed in.
>