4. Mutex: Anwendung wieder maximieren

Mutex: Anwendung wieder maximieren

  • A

    Schau dir doch mal das an:

    Artikel bei CodeProject

    Das sollte genau das machen, was du willst. In einer meiner Applikationen funktioniert es jedenfalls problemlos...

    0

  • Uff...
    Reichlich brutaler Code.

    0
  • C

    Warum nicht einfach mit RegisterWindowMessage und PostMessage eine Nachricht an das andere Programm schicken?

    0
  • ?

    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();
    0
  • Mod

    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... 😉

    0
  • A

    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...

    0
  • ?

    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!

    0
  • Mod

    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.

    0
  • ?

    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

    0
  • Mod

    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.

    0

  • 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.

    0
Anmelden zum Antworten