Preventing multiple instances - but also handle the command line parameters?

Question

I am handling from my Application associated extension files from Windows. So when you double click a file from Windows it will execute my program, and I handle the file from there, something like:

procedure TMainForm.FormCreate(Sender: TObject);
var
  i: Integer;
begin
  for i := 0 to ParamCount -1 do
  begin
    if SameText(ExtractFileExt(ParamStr(i)), '.ext1') then
    begin
      // handle my file..

      // break if needed
    end else
    if SameText(ExtractFileExt(ParamStr(i)), '.ext2') then
    begin
      // handle my file..

      // break if needed
    end else
  end;
end;

That works pretty much how I want it to, but when I was testing I realised it does not consider using only one instance of my program.

So for example, if I selected several Files from Windows and opened them all at the same time, this will create the same number of instances of my program with the number of Files being opened.

What would be a good way to approach this, so that instead of several instances of my program being opened, any additional Files from Windows being opened will simply focus back to the one and only instance, and I handle the Files as normal?

Thanks

UPDATE

I found a good article here: http://www.delphidabbler.com/articles?article=13&part=2 which I think is what I need, and shows how to work with the Windows API as mentioned by rhooligan. I am going to read through it now..

Answer 1

Here is some simple example code that gets the job done. I hope it is self-explanatory.

program StartupProject;

uses
  SysUtils,
  Messages,
  Windows,
  Forms,
  uMainForm in 'uMainForm.pas' {MainForm};

{$R *.res}

procedure Main;
var
  i: Integer;
  Arg: string;
  Window: HWND;
  CopyDataStruct: TCopyDataStruct;
begin
  Window := FindWindow(SWindowClassName, nil);
  if Window=0 then begin
    Application.Initialize;
    Application.MainFormOnTaskbar := True;
    Application.CreateForm(TMainForm, MainForm);
    Application.Run;
  end else begin
    FillChar(CopyDataStruct, Sizeof(CopyDataStruct), 0);
    for i := 1 to ParamCount do begin
      Arg := ParamStr(i);
      CopyDataStruct.cbData := (Length(Arg)+1)*SizeOf(Char);
      CopyDataStruct.lpData := PChar(Arg);
      SendMessage(Window, WM_COPYDATA, 0, NativeInt(@CopyDataStruct));
    end;
    SetForegroundWindow(Window);
  end;
end;

begin
  Main;
end.

 

unit uMainForm;

interface

uses
  Windows, Messages, SysUtils, Classes, Controls, Forms, StdCtrls;

type
  TMainForm = class(TForm)
    ListBox1: TListBox;
    procedure FormCreate(Sender: TObject);
  protected
    procedure CreateParams(var Params: TCreateParams); override;
    procedure WMCopyData(var Message: TWMCopyData); message WM_COPYDATA;
  public
    procedure ProcessArgument(const Arg: string);
  end;

var
  MainForm: TMainForm;

const
  SWindowClassName = 'VeryUniqueNameToAvoidUnexpectedCollisions';

implementation

{$R *.dfm}

{ TMainForm }

procedure TMainForm.CreateParams(var Params: TCreateParams);
begin
  inherited;
  Params.WinClassName := SWindowClassName;
end;

procedure TMainForm.FormCreate(Sender: TObject);
var
  i: Integer;
begin
  for i := 1 to ParamCount do begin
    ProcessArgument(ParamStr(i));
  end;
end;

procedure TMainForm.ProcessArgument(const Arg: string);
begin
  ListBox1.Items.Add(Arg);
end;

procedure TMainForm.WMCopyData(var Message: TWMCopyData);
var
  Arg: string;
begin
  SetString(Arg, PChar(Message.CopyDataStruct.lpData), (Message.CopyDataStruct.cbData div SizeOf(Char))-1);
  ProcessArgument(Arg);
  Application.Restore;
  Application.BringToFront;
end;

end.

Answer 2

The logic goes something like this. When you start your application, you iterate through the list of running processes and see if your application is already running. If it is running, you need to activate the window of that instance and then exit.

Everything you need to do this is in the Windows API. I found this sample code on CodeProject.com that deals with processes:

http://www.codeproject.com/KB/system/Win32Process.aspx

On finding and activating a window, the basic approach is to find the window of interest using the window class name then activate it.

http://www.vb6.us/tutorials/activate-window-api

Hopefully this gives you a good starting point.

Answer 3

There are many answers here that show how to implement this. I want to show why NOT to use the FindWindow approach.

I am using FindWindow (something similar with the one shown by David H) and I have seen it failed starting with Win10 - I don't know what they changed in Win10.
I think the gap between the time when the app starts and the time when we set the unique ID via CreateParams is too big so another instance has somehow time to run in this gap/interval.

Imagine two instances started at only 1ms distance (let's say that the user click the EXE file and then presses enter and keeps it pressed by accident for a short while). Both instances will check to see if a window with that unique ID exists, but none of them had the chance to set the flag/unique ID because creating the form is slow and the unique ID is set only when the form is constructed. So, both instances will run.

So, I would recommend the CreateSemaphore solution instead: https://stackoverflow.com/a/460480/46207
Marjan V already proposed this solution but didn't explained why it is better/safer.

Answer 4

I used window/message approach by myself with addition of events for tracking if the other instance is running:

1. Try to create event "Global\MyAppCode" (the "Global" namespace is used for handling various user sessions as I needed single instance system-wide; in your case you'll probably prefer "Local" namespace which is set by default)
2. If CreateEvent returned error and GetLastError = ERROR_ALREADY_EXISTS then the instance is running already.
3. FindWindow/WM_COPYDATA to transfer data to that instance.

But the drawbacks with messages/windows are more than significant:

1. You must always keep your window's Caption constant. Otherwise you'll have to list all the windows in the system and loop through them for partial occurrence of some constant part. Moreover the window's caption could be easily changed by a user or 3rd part app so the search would fail.
2. Method requires a window to be created so no console/service apps, or they must create a window and perform message loop especially for handling the single instance.
3. I'm not sure FindWindow could find a window that is opened in another user session
4. For me, WM_COPYDATA is rather awkward method.

So currently I'm a fan of named pipe approach (haven't implemented it yet though).

1. On launch, app tries to connect to "Global\MyAppPipe". If successed, other instance is running. If failed, it creates this pipe and finishes instance check.
2. 2nd instance writes the required data to pipe and exits.
3. 1st instance receives data and does some stuff.

It works through all user sessions (with namespace "Global") or just a current session; it doesn't depend on strings used by UI (no localization and modification issues); it works with console and service apps (you'll need to implement pipe reading in a separate thread/message loop though).

Answer 5

I'd use mutexes. You create one when your program starts.

When the creation fails it means another instance is already running. You then send this instance a message with your command line parameters and close. When your app receives a message with a command line, it can parse the parameters like you are already doing, check to see whether it already has the file(s) open and proceed accordingly.

Processing this app specific message ia also the place to get your app to the front if it isn't already. Please do this politely (SetForegroundWindow) without trying to force your app in front of all others.

function CreateMutexes(const MutexName: String): boolean;
// Creates the two mutexes to see if the program is already running.
//  One of the mutexes is created in the global name space (which makes it
//  possible to access the mutex across user sessions in Windows XP); the other
//  is created in the session name space (because versions of Windows NT prior
//  to 4.0 TSE don't have a global name space and don't support the 'Global\'
//  prefix).
var
  SecurityDesc: TSecurityDescriptor;
  SecurityAttr: TSecurityAttributes;
begin
  // By default on Windows NT, created mutexes are accessible only by the user
  //  running the process. We need our mutexes to be accessible to all users, so
  //  that the mutex detection can work across user sessions in Windows XP. To
  //  do this we use a security descriptor with a null DACL. 
  InitializeSecurityDescriptor(@SecurityDesc, SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(@SecurityDesc, True, nil, False);
  SecurityAttr.nLength := SizeOf(SecurityAttr);
  SecurityAttr.lpSecurityDescriptor := @SecurityDesc;
  SecurityAttr.bInheritHandle := False;
  if (CreateMutex(@SecurityAttr, False, PChar(MutexName)) <> 0 )
  and (CreateMutex(@SecurityAttr, False, PChar('Global\' + MutexName)) <> 0 ) then
    Result := True
  else
    Result := False;
end;

initialization
  if not CreateMutexes('MyAppNameIsRunningMutex') then
    //Find and SendMessage to running instance
    ;
end.

Note: above code is adapted from an example on the InnoSetup site. InnoSetup creates installer applications and uses this approach in the installer to check whether (a previous version of) the application being installed is already running.

Finding the other instance and sending it a message, I'll leave for another question (or you can use the WM_COPYDATA approach from David's answer). Actually, there is a StackOverflow question that deals exactly with this: How to get the process thread that owns a mutex Getting the process/thread that owns the mutex may be a bit of a challenge, but the answers to this question do address ways to get the information from one instance to the other.

Answer 6

Windows has different ways to handle file associations to executable.

The "command line" approach is only the simplest one, but also the most limited one.

It also supports DDE (it still works although officially deprecated) and COM (see http://msdn.microsoft.com/en-us/library/windows/desktop/cc144171(v=vs.85).aspx).

If I recall correctly both DDE and COM will let your application receive the whole list of selected files.