4. Problem mit OnActivate

Problem mit OnActivate

  • R

    Hallo Leute
    Möchte mein Programm so hinkriegen,dass es nie
    in den Hintergrund fällt,da ein anderes
    Programm den ganzen Desktop mit Task-Leiste überdeckt.
    In dem Fall könnte der Bediener das Programm nicht
    mehr schliessen.

    Ich habs zuerst mit der Funktion OnActivate probiert.
    Das Programm stratet zwar(wie ich im Task-Manager seh)
    wird aber nicht sichtbar,und der benutzte Speicher wird immer
    grösser.

    Cmeineklasse::OnInitDialog()
{
OnActivate(WM_ACTIVATE,GetWindow(102),false);
return TRUE;
}

Cmeinklasse::OnActivate(nState,CWnd *pOtherWnd,bMinimized)
{
if(nState==WA_INACTIVE)
{
SetWindowPos(....)
}
CWnd::OnActivate(nState,pOtherWnd,bMinimized)
}

    Kann mir jemand helfen?
    Weiss nicht mehr,was ich noch tun soll

    Danke schon im voraus

    0
  • _

    Wozu OnActivate() ?
    Schreib SetWindowPos() doch gleich in die InitDialog...!?

    Gruß
    :: NoName ::

    P.S. Den Taskmanager kann man aber nicht überdecken...

    0
  • R

    Hab geschrieben,
    die TASK-LEISTE wird überdeckt.

    Dieses 2.Programm ist eine spezielle
    Visualisierungssoftware für Maschinensteuerungen.

    Der Sinn des Überdeckens ist:
    Der Bediener der Maschine kann auf WindowsEbene
    keinen Müll produzieren.

    Das SetWindowPos funktioniert schon.

    Doch wenn ich neben den Dialog klicke verschwindet
    mein Dialog hinter der Visualisierung

    Den ClipCursor kann ich nicht dazu benutzen,da das ganze
    über ein Touch-Panel bedient wird

    0
  • P

    Such das Fenster der Anwendung mit FindWindow() o.ae., und gib es als Parent beim Erstellen Deines Fensters an. Bei WS_OVERLAPPEDWINDOW Fenstern etabliert dies eine Owner-Beziehung. Dann ist Dein Window immer ueber dem anderen Window. 🙂

    0
  • R

    Kannst du mir das genauer erklären?

    Das SetParent hab ich hingekriegt.
    Ist im OnInitDialog richtig.Oder?

    Aber das mit dem WS_Overlappedwindow krieg ich nicht
    auf die Reihe.
    Auch mit dem MSDN komm ich nicht klar

    0
  • P

    Geht auch bei Dialogen. SetParent() ist ok.

    Geh mal zu http://msdn.microsoft.com/library/ .

    Unter "Platform SDK" findest Du moeglicherweise einen Download-Link, ueber den Du das 2003er Platform SDK downloaden kannst.

    Man kann die Library aber auch online browsen.

    0
  • R

    Gibt kein Codebeispiel für SetParent.

    Aber kann mir denn niemand beim OnActivate-Problem
    helfen?

    0
  • P

    Probier doch mal, anstatt eines Dialoges ein normales Fenster zu verwenden, das Du mit CreateWindowEx() erzeugst. Entweder Du gibst den Parent gleich beim CreateWindowEx() an, oder im WM_CREATE-Handler ueber SetParent(). Das muss gehen. Du musst natuerlich das Fenster-Handle der Anwendung ermitteln, das Du ueberdecken willst. Dafuer kannst Du FindWindow() oder FindWindowEx() verwenden, die in der Windows-API-Dokumentation beschrieben sind. Hab leider grad kein Windows da, sonst koennt ich Dir einen Beispiel-Code schreiben.

    0
  • R

    Wär das nicht en bisschen grosser Aufwand,um das
    ganze Projekt auf Fensterbasierend umzubauen?
    Hab sowas noch nie gemacht.
    Und mein Programm ist auch schon reichlich gross
    mit mehreren Dialogen

    0
  • P

    Du kannst auch ein neues Fenster aufmachen, auf dem Du dann Deine Dialoge darstellst. Das Fenster muss jedoch Child von der Anwendung sein, die Du ueberdecken willst.

    Wenn es mehrere Fenster mit dem Stil WS_EX_TOPMOST gibt, wird immer das, das gerade aktiviert ist, in den Vordergrund geholt. Deshalb ist die Owner-Parent-Loesung m.E. die einzig praktikable in Deinem Fall.

    Windows ist halt kein OS/2 (mit klaren Parent-Owner-Beziehungen) und auch kein UNIX (mit X Windows, bei dem eh alles moeglich ist).

    Es gibt im Windows keine statische Z-Order, mit der Du die Z-Position (Prioritaet) des Fensters festlegen kannst.

    Die einzig andere Loesung, die mir noch einfaellt, waere, ueber DirectX 9 einen Overlay zu erzeugen, und dann mittels GDI in den Overlay zu zeichnen. Dann musst Du aber Deine Dialoge selber malen. Oder Du zeichnest direkt auf die Primaeroberflaeche des Videospeichers (also das, was man sieht).

    Oder aber, die Anwendung, die Du ueberdecken moechtest, ruft Deine Dialoge direkt auf (indem Deine Dialoge in die Hauptanwendung eingebunden werden).

    Es gibt noch einige andere Moeglichkeiten, dann musst Du aber von der MFC Abstand nehmen. (Toll gell, so'n Application Wizard, dann kommt man gar nicht auf die Idee, dass es noch ganz andere Moeglichkeiten gibt)

    Jedenfalls wirst Du moeglicherweise nicht drum rum kommen, Dir die MFC und auch den Windows API naeher anzugucken.

    Die MFC ist den realen Beduerfnissen von Anwendungen einigermassen entrueckt, da sie nur SDI- (wie Wordpad), MDI- (wie Word) und dialogbasierte Anwendungen (wie Systemeinstell-Applets) unterstuetzt, was in der Realitaet nicht unbedingt vorkommt. Z.B. erfordert die Erstellung einer Anwendung, die vom View/Document-Konzept unabhaengig ist, entweder eine dialogbasierte Anwendung (was nicht immer Sinn macht), oder eine abgewandelte SDI-Anwendung, bei der man von Hand alle View/Document-Bezuege entfernt (steht auch in der MFC-Beschreibung). Ansonsten kann man auf MFC gleich ganz verzichten, und eine reine Win32-Anwendung schreiben, oder man muss halt alles so hinbiegen, wie man es braucht, was wahrscheinlich den Regelfall darstellt.

    Eine Loesung waere es noch, wie oben angegeben den Stil WS_EX_TOPMOST zu verwenden (bevor AfxRegisterClass aufgerufen wird), und dann mit einem Timer die Dialoge immer den Vordergrund zu schicken (ach nee, SetForegroundWindow() ist ja bei XP nicht mehr erlaubt, ausser die betroffene Anwendung gestattet es Dir, siehe SetForegroundWindow()-Doku).

    0
  • R

    Bin jetzt schon en stück weiter.
    Das Problem mit dem OnActivate hab ich gelöst.
    Darf den Event nicht aufrufen im OnInitDialog.
    Da mein Dialog noch gar nicht existiert.

    Habs mit der MessageBox geprüft.

    Jetzt ist aber ein neues Problem aufgetreten.

    Im OnInitDialog ruf ich
    SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
    auf.Dies bringt meinen Dialog nach vorne.
    Wenn er jedoch minimiert wird,und ich
    SetWindowPos(...)
    wieder aufrufe funktioniert es nicht mehr.
    Vermute,dass es am "&this->wndTopMost" liegt.

    Hat jemand ne Ahnung?

    0
Anmelden zum Antworten