Verhindern eine Anwendung mehrfach zu starten

[HolgerX]

Hmm..

Zitat:

Zitat von Delphi.Narium (Beitrag 1500530)

Das ist die einfachste Lösung, wenn man sicherstellen will, dass ein Programm nur einmal gestartet wird.

Was diese Lösung aber nicht kann:

Die übergebenen Parameter an die erste Instanz weiterreichen, damit diese damit weiterarbeiten kann.

Und genau da liegt ja aktuell das Problem.

Wieso sendest Du dann nicht eine Message an deine andere Instanz?

Z.B. in der DPR (wie oben als Beispiel)

Delphi-Quellcode:

const
  c_ProgStartMutexName = 'MeinProgrammName';



  {Attempt to create a named mutex}
  CreateMutex(nil, false, c_ProgStartMutexName);
  {if it failed then there is another instance}
  if GetLastError = ERROR_ALREADY_EXISTS then
    begin
    {Send all windows our custom message - only our other}
    {instance will recognise it}
    SendMessage(HWND_BROADCAST,
                RegisterWindowMessage(c_ProgStartMutexName),
                0,
                0);
    {Lets quit}
    Halt(0);
  end;
  Application.Initialize;

Dort, im Hauptfenster vorher:

Delphi-Quellcode:

const
  c_ProgStartMutexName = 'MeinProgrammName';

var
 OldWindowProc : Pointer; {Variable for the old windows proc}
 MyMsg   : Int64; {custom systemwide message}

function NewWindowProc(WindowHandle : hWnd;TheMessage   : LongInt;
  ParamW : LongInt; ParamL : LongInt) : LongInt stdcall;
begin
  if TheMessage = MyMsg then begin
    {Tell the application to restore, let it restore the form}
    SendMessage(Application.handle, WM_SYSCOMMAND, SC_RESTORE, 0);
    SetForegroundWindow(Application.Handle);
    {We handled the message - we are done}
    Result := 0;
    exit;
  end;
  {Call the original winproc}
  Result := CallWindowProc(OldWindowProc, WindowHandle, TheMessage, ParamW, ParamL);
end;

procedure TFormMeineMainForm.FormCreate(Sender: TObject);
begin
  //Register a custom windows message
  MyMsg := RegisterWindowMessage(c_ProgStartMutexName);
  //Set form1's windows proc to ours and remember the old window proc
  OldWindowProc := Pointer(SetWindowLong(FormHauptmenue.Handle, GWL_WNDPROC, LongInt(@NewWindowProc)));
  ..
end;

In diesem Beispiel wird der ersten Instanz einfach nur mitgeteilt, dass sie sich wieder nach vorne bringen soll..
Kannst aber auch eine andere Message oder IPC verwenden, um z.B. deinen Sting zu übergeben.

[himitsu]

Und wo übergibst du dort die "Parameter" ?

Die beiden verlinkten Units nutzen dafür WM_COPYDATA, um quasi GetCommandLine zu übergeben, wobei dort der Speicher für den "String" (damals ANSI und jetzt Unicode) falsch vewaltet wird/wurde, weswegen es nun nicht mehr im "neuen" Delphi funktioniert(e).



Man könnte es noch mit WM_SETTEXT/SendTextMessage versuchen, wo Windows notfalls die ANSI/Unicodeumwandlung vornehmen würde, falls nötig,
wenn man zu doof ungeschickt ist WM_COPYDATA richtig zu verwenden.

[Sinspin]

Zitat:

Zitat von Delphi.Narium (Beitrag 1500530)

Das ist die einfachste Lösung, wenn man sicherstellen will, dass ein Programm nur einmal gestartet wird.

Was diese Lösung aber nicht kann:

Die übergebenen Parameter an die erste Instanz weiterreichen, damit diese damit weiterarbeiten kann.

Und genau da liegt ja aktuell das Problem.

Kalt erwischt :oops:
Danke.

Ich arbeite mit Named Pipes zur Kommunikation meiner Programteile untereinander. Das zuerst gestartete macht den Server auf, nach dem dann alle anderen Teile suchen.
Das gleiche geht doch hier auch.

Wobei natürlich PostMessage viel eleganter ist solange man an das passende Handle kommt.

Die Datenübertragung erledigt eine serealisierte Memtable deren Daten als Bytestrom oder B64 String übertragen werden.

[HolgerX]

Hmm..

Zitat:

Zitat von himitsu (Beitrag 1500563)

Und wo übergibst du dort die "Parameter" ?

Ich hatte doch geschrieben

Zitat:

Zitat von HolgerX (Beitrag 1500548)

In diesem Beispiel wird der ersten Instanz einfach nur mitgeteilt, dass sie sich wieder nach vorne bringen soll..
Kannst aber auch eine andere Message oder IPC verwenden, um z.B. deinen Sting zu übergeben.

Da hier zwei getrennte Prozesse involviert sind, muss natürlich eine Übermittlung über einen entsprechenden Weg gemacht werden..
Ich würde auch nicht einfach die Parameter als Text hinschicken, sondern ggf. eine Recordstrucktur, welche dem Empfänger auch mitteilt, dass es sich um 'Parameter des Programmaufrufes' handelt. ;)

[HolgerX]

Hmm..

Zitat:

Zitat von Sinspin (Beitrag 1500581)

Ich arbeite mit Named Pipes zur Kommunikation meienr Programteile untereinander. Das zuerst gestartete macht den Server auf, nach dem dann alle anderen Teile suchen.
Das gleiche geht doch hier auch.

Wenn schon eine Pipe da ist, wieso dann nicht statt Mutex auf das Vorhandensein der Pipe prüfen, schießlich kann eine NamedPipe nur einmal erstellt werden (soweit ich weiß), wie bei einem Socketserver.

Dann kannst Du die Informationen direkt dorthin schicken, ist sogar besser, da nicht alle Messages mit UserData Prozess übergreifend verschickt werden.

Ach ja:
Kein Postmessage, sondern Sendmessage verwenden! Denn z.B. WM_COPYDATA funktioniert nur richtig damit..

[KodeZwerg]

Zitat:

Zitat von Delphi.Narium (Beitrag 1500508)

PBOnceOnly.pas

Jupp, genau das meinte ich. Ich hatte es lediglich um ein paar für mich speziellere Dinge erweitert wo ich mir gerade den Quelltext anschaue und vergleiche :-)
(ich wollte noch eine option haben die steuert ob programm a.exe parameter an b.exe übergibt, ob b.exe vor dem ".run" von a.exe terminiert werden soll usw... paar spielereien halt)
Wie dem auch sei, das rad muss nicht neu erfunden werden, soll nicht bedeuten das die Quelltexte der anderen falsch sind, um gottes willen nein, nur mach ich mir darüber keine gedanken mehr.
Lieber würde ich die PBOnceOnly.pas CrossPlatform fähig machen :-)

[Carsten Hölscher]

Zitat:

Zitat von himitsu (Beitrag 1500506)

Es lebe Unicode ... der Code war noch aus Zeiten von vor 2009 :stupid:

Hab's nicht getestet, aber ich denke mal so müsste es aussehn:

....

Ja, geht. Vielen Dank. Da war ich immerhin irgendwie schon ganz nah dran bei meinen eigenen Versuchen :-D

In dem Komponenten-Thema kann ich ja nicht schreiben, vielleicht kann es da jemand entsprechend aktualisieren?

Carsten