Wie findet man Fenster, deren Namen man nicht genau kennt?

[CCRDude]

Dateinamen können natürlich auch von anderen Anwendungen verwendet werden, und Pfade sind öft vom Benutzer wählbar.

Mutexe und Atome sind noch ein Stichwort.

Auch ein Tipp: mit Terminal Services siehst Du evtl. Prozesse, zu Denen Du keine Windows findest.

[ASM]

Zitat:

Wobei es auch sein kann, daß es andere Programme mit dem selben Fensternamen gibt,
oder das gefundene Fenster gehört zur gleichen EXE, aber in einem anderen Verzeichns.

Der einzige Weg, um ein bestimmtes Programm zu finden, geht also nur über den EXE Namen, inkl. Pfad.

Zitat:

Dateinamen können natürlich auch von anderen Anwendungen verwendet werden, und Pfade sind öft vom Benutzer wählbar.

Ganz recht.
Und dazu schaut man eben über die vorgeschlagene Funktion FindWindowEx() zunächst nach, ob überhaupt ein Fenster mit dem partiellen Titel der zu erfragenden Applikation existiert.
Falls nämlich nicht, hat sich die Sache bereits erledigt.
Falls ja, dann kann man sich entscheiden:
(a) die Zuordnung des Fensters ist aus dem Kontext unzweifelhaft eindeutig, womit das ohne weitere Abfragen geklärt wäre.
(b) man muss/möchte auf Nummer Sicher gehen und etwaige Zweifel an der Zuordnung des Fensters zur erfragten Applikation beseitigen: man hat ja mit dieser Funktion FindWindowEx() gleichzeitig das zu eben diesem Fenster zugehörige Handle und holt sich nun mit Hilfe dieses Handles vermittels des Prozesses den Filenamen inkl. kompletten Pfad der Applikation, zu dem das Fenster gehört. Womit das dann - ohne "Wenn" und "Aber" - definitiv und ggf. auch für mehrere Fenster mehrerer Instanzen, geklärt wäre.

Code:

function GetProcessNameFromWnd(Wnd: HWND): string;
var
  List: TStringList;
  PID: DWORD;
  I: Integer;
begin
  Result := '';
  if IsWindow(Wnd) then
  begin
    PID := INVALID_HANDLE_VALUE;
    Windows.GetWindowThreadProcessId(Wnd, @PID);
    List := TStringList.Create;
    try
      if RunningProcessesList(List, True) then
      begin
        I := List.IndexOfObject(Pointer(PID));
        if I > -1 then
          Result := List[I];
      end;
    finally
      List.Free;
    end;
  end;
end;

Im weiteren (insbes. zur noch benötigten RunningProcessesList()) siehe http://www.delphitricks.com/source-c...ow_handle.html

[CCRDude]

Zitat:

Zitat von ASM (Beitrag 1124324)

Und dazu schaut man eben über die vorgeschlagene Funktion FindWindowEx() zunächst nach, ob überhaupt ein Fenster mit dem partiellen Titel der zu erfragenden Applikation existiert.
Falls nämlich nicht, hat sich die Sache bereits erledigt.

Desewegen erwähnte ich Terminal Services. Die als Remote-Desktop-Verbindung inzwischen ja nicht mehr nur im großen Firmenumfeld vorkommen. Oder war sogar Fast User Switching darüber?

MSDN sagt zu FindWindowEx:

Zitat:

If hwndParent is NULL, the function uses the desktop window as the parent window. The function searches among windows that are child windows of the desktop.

Als Wurzel der Suche kann man also nur einen Desktop verwenden; ist parallel eine Person zwei angemeldet und benutzt das Programm, würde FindWindowEx aber scheitern.

Deswegen mein Tipp zu Techniken, die session-übergreifend funktionieren.

[ASM]

Zitat:

Zitat von CCRDude (Beitrag 1124342)

MSDN sagt zu FindWindowEx: ...

Als Wurzel der Suche kann man also nur einen Desktop verwenden; ist parallel eine Person zwei angemeldet und benutzt das Programm, würde FindWindowEx aber scheitern.

Nur um keine Verwirrung aufkommen zu lassen: die von mir oben gepostete Funktion FindWindowEx() ist nicht die in der Unit deklarierte Funktion FindWindowEx() aus der MS-Systemlibrary user32.dll. Besser hätte ich die von mir gepostete Funktion wohl FindWindowPart() oder sonstwie nennen sollen, um diesen Unterschied klar zu machen. Letztlich stellt der neu angemerkte potentielle Remote-Effekt aber wohl das gleiche Problem für beide Funktionen dar.

Davon allerdings, dass es sich hier in der Diskussion um ein Server-Client spezifisches Problem handeln könnte, war bisher jedoch nicht erkennbar die Rede. Dadurch wird die Fragestellung jetzt unerwartet mit einer erheblich anderen Zielrichtung aufgeworfen als ursprünglich gestellt. Oder ich hatte dahingehend etwas falsch verstanden ...

[himitsu]

Versuche einfach die nötigen Dateien exklusiv und mit Schreibrechten zu öffnen.
Geht das nicht, dann "Update nicht möglich, da Programm läuft oder Zugriffsrechte fehlen".

[CCRDude]

Zitat:

Zitat von ASM (Beitrag 1124379)

Davon allerdings, dass es sich hier in der Diskussion um ein Server-Client spezifisches Problem handeln könnte, war bisher jedoch nicht erkennbar die Rede.

Deswegen ja meine Ergänzung, daß Terminal Services früher vllt. mal Client-Server-Architektur only gewesen sein mögen, heute aber dank Fast User Switching recht verbreitet angewendet sind (und deutlich seltener, aber auch noch im Home-Bereich, mit dem Remote Desktop).

MSDN lädt sich bei mir heute leider meist tot, daher kann ich nur blind die Lektüre zu den WTS*-Funktionen empfehlen :)

[Sir Rufo]

Soll dieses Updateprogramm unbedingt selber geschrieben werden oder darf es auch was fertiges sein?

Dann würde ich z.B. InnoSetup vorschlagen.

Laufende Instanzen des Programms werden von InnoSetup über einen Mutex erkannt.
InnoSetup kann Dateien nachladen
InnoSetup kann Dateien kopieren, auch wenn die Datei gesperrt ist (Neustart erforderlich)

Für TerminalServices sollte ein globaler Mutex verwendet werden!
Prefix

Code:

Global/