Wurde im Parent einer eigenen Kompo geklickt?

[Gast]

OK jetzt bin ich denke ich mal ziemlich durcheinander gekommen...
Also ich habe jetzt:

/*  Header-Datei  */
public:
        __fastcall TColoredPopUpMenu(TComponent* Owner); // Ist ja Standard immer drin
        virtual __fastcall ~TColoredPopUpMenu();
private:
        TMessageEvent DefaultApplicationMessage;
protected:
        void __fastcall CreateWnd(void);
        void __fastcall OnAppMessage(MSG& Msg, bool& Handled);

//----------------------------------------------------------------------

  /*  cpp-Datei  */
__fastcall TColoredPopUpMenu::TColoredPopUpMenu(TComponent* Owner)
        : TCustomControl(Owner)
{
}
//---------------------------------------------------------------------------
__fastcall TColoredPopUpMenu::~TColoredPopUpMenu()
{
  Application->OnMessage = DefaultApplicationMessage;
}
//---------------------------------------------------------------------------
void __fastcall TColoredPopUpMenu::CreateWnd(void)
{
  TCustomControl::CreateWnd();
  DefaultApplicationMessage = Application->OnMessage;
  Application->OnMessage    = OnAppMessage;
}
//---------------------------------------------------------------------------
void __fastcall TColoredPopUpMenu::OnAppMessage(MSG& Msg, bool& Handled)
{
  if(DefaultApplicationMessage)
  {
    DefaultApplicationMessage(Msg,Handled);
  }
  if(Visible && Msg.hwnd != Handle && Msg.message==WM_RBUTTONDOWN)
  {
     ShowMessage("Tach Auch");
  }
}
//---------------------------------------------------------------------------

Wieder mal empfängt der garnichts?!? Warum nicht?

MFG Aoeke

[AndreasW]

Hi,

sieht doch gut aus. Wo klickst du denn mit der rechten Maustaste drauf ?

[Gast]

Na also ich habe die Kompo jetzt halt Manuell in ein Projekt gepackt, wo der
Parent = Form1 ist.
Und da klicke ich dann auch mit Rechts rauf und nichts passiert...
Kein "Tach auch" erscheint...

MFG Aoeke

P.S. Man ich muss dich hier jetzt ja mal loben, so schnell wie die Antworten
immer kommen...

[AndreasW]

Hi,

setzt mal in der Methode OnAppMessage HAltepunkte. Prüfe ob dort überhaupt Nachrichten ankommen.

DAs musse eigentlich funktionieren.

[Gast]

Prüfe ob dort überhaupt Nachrichten ankommen.
DAs musse eigentlich funktionieren.

Nope. Leider nicht. Es kommt nichts an.
Warum ist das nur alles so schwierig???

MFG Aoeke

[Fritz]

Hast du auch das geheime Hauptfenster überhaupt erstellt?

[Gast]

Original erstellt von <Fritz>:
Hast du auch das geheime Hauptfenster überhaupt erstellt?

Was meinst du jetzt damit???

MFG Aoeke

[WebFritzi]

Application->OnMessage ist hier IMHO total unangebracht. Der Benutzer der Kompo weiß ja nichts davon. Was nun, wenn er Application->OnMessage eine andere Funktion zuweist?
Die neue WindowProc für das Parent braucht nicht in den Quelltext der Parent-Klasse!

[AndreasW]

hm,

setz mal vor der Zeilen einen Haltepunkt:

-> Application->OnMessage = OnAppMessage;
-> if(Visible && Msg.hwnd != Handle && Msg.message==WM_RBUTTONDOWN)

Der Debugger müsste bei beiden halten.

Das muss funktionieren...

[WebFritzi]

@Aoenke: Er ist ein Troll. Ignoriere ihn und lies dir lieber meine letzten Beitrag auf Seite 1 durch.

[Fritz]

Ich bin überhaupt kein Troll. Das mit dem geheimen Fenster steht sogar in den FAQs.

[Gast]

Original erstellt von WebFritzi:
Die neue WindowProc für das Parent braucht nicht in den Quelltext der Parent-Klasse!

Also kann ich das auch in den Kompo-Quelltext reinbringen ja???
Aber wenn ich das mache, fängt der doch die Messages von der Kompo ab, oder
irre ich mich da???

@ AndreasW : Der hält aber bei keinem der beiden...

MFG Aoeke

[AndreasW]

Original erstellt von WebFritzi:
Application->OnMessage ist hier IMHO total unangebracht. Der Benutzer der Kompo weiß ja nichts davon. Was nun, wenn er Application->OnMessage eine andere Funktion zuweist?
Die neue WindowProc für das Parent braucht nicht in den Quelltext der Parent-Klasse!

ähm, das Problem besteht immer. Mit dein Vorschlag die WindowProc des Parent zu überschreiben machst du ja genau das selbe. Beides sind Funktionspointer.
Nur das deine Version ein Hacken hat. Der Parent könnte ja auch ein Panel sein. Was ist nun , wenn der User auf ein andere Panel klickt ? Das kannst du dann ja nicht mehr abdecken... Sogesehen ist dein Lösungsansatz wohl unangebracht.

[AndreasW]

ziehe folgende CodeZeilen in den Konstruktor:

DefaultApplicationMessage = Application->OnMessage;
  Application->OnMessage    = OnAppMessage;

dann müsste es gehen...

[Gast]

OK das geht erstmal, der empfängt Messages...

if(/*Visible && Msg.hwnd != Handle && */Msg.message == WM_RBUTTONDOWN)
  {
     ShowMessage("Tach Auch");
  }

Das Visible && Msg.hwnd != Handle habe ich erstmal "weggemacht", da der
mir dann immer die Exception Element " hat kein übergeordnetes Fenster.
aufn Tisch schmeißt...
Jetzt reagiert der aber auf alle WM_RBUTTONDOWN der gesamten Anwendung...
Wie kann ich das jetzt machen, dass der nur die des Parent verwendet???

[AndreasW]

//---------------------------------------------------------------------------
void __fastcall TMLPopUpWindow::OnAppMessage(MSG& Msg, bool& Handled)
{
if(DefaultApplicationMessage && DefaultApplicationMessage!=OnAppMessage)
      DefaultApplicationMessage(Msg,Handled);
  if(Showing &&HandleAllocated() && Msg.hwnd!=Handle &&(Msg.message==WM_LBUTTONDOWN || Msg.message==WM_RBUTTONDOWN))
      {
        if(Msg.hwnd==Parent->Handle)
          {
             // mach was 
          }
      }

[ Dieser Beitrag wurde am 09.03.2003 um 21:42 Uhr von AndreasW editiert. ]

[ Dieser Beitrag wurde am 09.03.2003 um 21:43 Uhr von AndreasW editiert. ]

[AndreasW]

Original erstellt von Aoeke:
[QB]Das Visible && Msg.hwnd != Handle habe ich erstmal "weggemacht", da der
mir dann immer die Exception Element " hat kein übergeordnetes Fenster.
aufn Tisch schmeißt...

Deshalb hatte ich die Zeilen in CreateWnd. Du hast irgendwie diese Methode nicht richtig überschrieben, sodass deine Methode nie Aufgerufen wurde.

[Gast]

Msg.hwnd != Handle : ==> Element " hat kein übergeordnetes Fenster.
Ich hab den Rest auch mal überprüft: Showing ist false, genauso wie
HandleAllocated()...

MFG Aoeke

*Letzter Beitrag für heute... Ich schau morgen wieder rein!!!*

[WebFritzi]

Original erstellt von AndreasW:
**
ähm, das Problem besteht immer. Mit dein Vorschlag die WindowProc des Parent zu überschreiben machst du ja genau das selbe. Beides sind Funktionspointer.**

Da hste recht. Hab ich nicht dran gedacht.

Original erstellt von AndreasW:
**
Nur das deine Version ein Hacken hat. Der Parent könnte ja auch ein Panel sein. Was ist nun , wenn der User auf ein andere Panel klickt ? Das kannst du dann ja nicht mehr abdecken... Sogesehen ist dein Lösungsansatz wohl unangebracht**

Hier verstehe ich nicht, was du meinst. Wo soll das andere Panel liegen? Ebenfalls im Parent-Panel? Dann wird bei deiner Lösung aber auch nichts ausgelöst:

if(Msg.hwnd==Parent->Handle)
{
// mach was
}

Die Frage ist auch, ob Aoenke das überhaupt will. Möchte er, dass die Message immer behandelt wird, wenn nur auf ein Fenster geklickt wird, das ein Child vom Parent-Panel ist? Oder möchte er nur auf Klicks direkt im Parent-Panel reagieren? Ich denke, hier ist eher die zweite Version üblich.

[AndreasW]

Original erstellt von WebFritzi:
**
Hier verstehe ich nicht, was du meinst. Wo soll das andere Panel liegen? Ebenfalls im Parent-Panel? Dann wird bei deiner Lösung aber auch nichts ausgelöst:
[quote]
if(Msg.hwnd==Parent->Handle)
{
// mach was
}
**

[/QUOTE]

richtig. Hab ich hier nicht implementiert. Irgendwas muss er ja auch noch selbst machen.

Er will ein PopUpMenü basteln. Ein PopUpMenu verschwindet, wenn man irgendow ausserhalb des Menues klickt. Zumindest normalerweise. Um nun zu testen, ob ausserhalb eines Steuerelementes geklickt wurde reicht das Überschreiben der WindowProc des Parent nicht aus. Stell dir vor er legt das PopUpMenü auf ein Panel. Diese macht er genauso groß wie das Menü selbst. Ist natürlich Kecks, aber ja möglich. Der Anwender würde dann ja niemals auf den Parent klicken können. Auf andere etweilige Panels im Formular reagiert das Steuerelement nun aber nicht, weshalb das Steuerelement nicht ausgeblendet wird. Man kann natürlich die WindowProc des Forulars (ParentForm) überschreiben. Das hilft aber auch nur, wenn keine Panels oder andere Steuerelemente auf dem Formular liegen usw...

Deshalb is OnAppMessage hier gut geeignet, da das Reaktionsvermögen nicht auf ein Fensterhandle beschränkt ist.
Man kann auch mit Component[i] des ParentForm die platziereten Komponenten durchgehen, deren Handle mit den Msg.Handle vergleichen und so feststellen, worauf nun geklickt wurde. In der Regel braucht man das aber nicht.
Was sinnvoll wäre ist das Ausschließen eigener Subkomponenten aus diesen Routinen. Wenn im Steuerelement z.B. Ein Edit- Feld ist, ist es ja nicht unbedingt sinnvoll die Komponente bei Klick auf das Edit- Feld inm Menü zu schliessen. Da könnte man unterbinden, indem man generell die Handles der Subkomponenten ausschleisst.

Original erstellt von WebFritzi:
**
Die Frage ist auch, ob Aoenke das überhaupt will. Möchte er, dass die Message immer behandelt wird, wenn nur auf ein Fenster geklickt wird, das ein Child vom Parent-Panel ist? Oder möchte er nur auf Klicks direkt im Parent-Panel reagieren? Ich denke, hier ist eher die zweite Version üblich.**

insofern denke ich, dass dieses genau das ist was er möchte...

[ Dieser Beitrag wurde am 09.03.2003 um 22:39 Uhr von AndreasW editiert. ]