Mutex: Anwendung wieder maximieren
-
Eine Lösung gibt es hier:
http://www.flounder.com/nomultiples.htm
-
Da steht aber auch kein wirklich guter Weg drinnen wie man die andere Instanz dann in den Vordergrund bringen kann.
Eine Möglichkeit wäre ein anonymes File-Mapping statt der Shared-Variable zu verwenden. Ist aber reichlich viel Aufwand für so ein "kleines" Feature.
Seit ich damals, kurz nach dem Krieg, von Amiga-OS zu Windows gewechselt habe, frage ich mich, warum es in Windows kein Kernel-Objekt mit nem "dwUserdata" gibt. Würde einiges vereinfachen...
In diesem Fall könnte man einfach das Window-Handle in das "dwUserdata" der Mutex reinstecken, könnte sich also weiteren Aufwand mit File-Mapping/... sparen.
-
Schau dir doch mal das an:
Das sollte genau das machen, was du willst. In einer meiner Applikationen funktioniert es jedenfalls problemlos...
-
Uff...
Reichlich brutaler Code.
-
Warum nicht einfach mit RegisterWindowMessage und PostMessage eine Nachricht an das andere Programm schicken?
-
Danke euch! Ich habe es hinbekommen mittels einer message die ich sende
und dann in Windowproc darauf reagiere.Das Fenster wieder in den Vordergrund zu holen ist aber etwas tricky:
DWORD lockTimeOut = 0; HWND hCurrWnd = ::GetForegroundWindow(); DWORD dwThisTID = ::GetCurrentThreadId(), dwCurrTID = ::GetWindowThreadProcessId(hCurrWnd,0); //we need to bypass some limitations from Microsoft if(dwThisTID != dwCurrTID) { ::AttachThreadInput(dwThisTID, dwCurrTID, TRUE); ::SystemParametersInfo(SPI_GETFOREGROUNDLOCKTIMEOUT,0,&lockTimeOut,0); ::SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT,0,0,SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE); ::AllowSetForegroundWindow(ASFW_ANY); } SetForegroundWindow();
-
Wieso denn das?
Wenn die andere Anwendung gerade gestartet wird, dann ist sie aktiv und kann jeden und alles in den Vordergrund bringen.
Nur die Anwednung selbst darf es nicht...
-
hustbaer schrieb:
Uff...
Reichlich brutaler Code.Wieso?
Muss ich da jetzt Angst um die Stabilität meiner Programme haben? Wie gesagt, bislang laufen sie seit mehreren Jahren ohne Probleme...
Oder ist es einfach "unsauber" programmiert und solange es läuft, ist gut...Ich bin nicht so der große Experte und nutze gerne fertigen Code, auch wenn ich den nicht so ganz verstehe...
-
Martin Richter schrieb:
Wieso denn das?
Wenn die andere Anwendung gerade gestartet wird, dann ist sie aktiv und kann jeden und alles in den Vordergrund bringen.
Nur die Anwednung selbst darf es nicht...Martin, wie würdest du es denn lösen?
Ich bitte um einen alternativen, vielleicht sogar besseren, Lösungsansatz!
-
Den ich löse es ähnlich wie der Code Flounder.
1. Die zuerst startende Anwendung erzuegt Mutex und eine memory maped file.
2. Der Mutex wird auch benützt um den Zugriff auf die File zu kontrollieren.
3. Die Startende Anwednung legt den Mutex an und trägt das Windows Handle in die Memory Mapped file.
4. Die zweite Anwendnung findet den Mutex, öffnet die Datei, holt das Handle und führt SetForegroundWindow aus.
-
Ein Fenster handle habe ich ja. Nur SetForeGroundWindow reagiert insofern nicht,
als dass es das Fenster nicht wieder Sichtbar macht.Ich habe mich daran orientiert und es somit gelöst:
http://www.codeproject.com/Tips/76427/How-to-bring-window-to-top-with-SetForegroundWindo
-
Wenn Dein Programm bereits gestartet ist.
Wenn dann Dein Programm nochmals gestartet wird, dann ist dieses Programm das aktive! Dann hat dieses programm das Recht jedes andere Programm in den Vordergrund zu bringen.Das geht bei mir ohne Klimmzüge!
Was anderes ist, wenn Dein Programm durch irgendwas gestartet wird und nicht durch den Userr, dann ist das Verhalten natürlich klar.
-
AndRo67 schrieb:
hustbaer schrieb:
Uff...
Reichlich brutaler Code.Wieso?
Weiss nicht wie ich das beschreiben soll...
Ich finde es krass in so einem Fall nen global-atom zu erzeugen und eine Nachricht an alle Top-Level Fenster zu schicken.
Noch dazu wobei die 2. Instanz des eigenen Programms dann dafür zuständig ist den global atom wieder zu löschen.Muss ich da jetzt Angst um die Stabilität meiner Programme haben?
Nein, das nicht.
Maximal könnte der global atom "übrigbleiben", was nicht schlimm ist, so lange du das Programm nicht mit millionenfach mit immer unterschiedlichen Commandline-Parametern startest.
