Subclass/Wnd-Nachrichten - Ergänzung zur Tooltipsfrage

Martin Richter

Was heißt hier Parent oder Child Loop?

Am einfachsten ist es jede Maus-Nachricht, die für das Fenster mit dem Tooltip ist an das Tooltip Control weiterzuleiten.

Das macht man am Besten in der Messageloop.
Oder Du kannst auch in die WndProc des Fensters die Nachricht direkt weiterleiten.

peteur schrieb:

case WM_MOUSEMOVE:
  MSG msg;
  POINT pt;
  GetCursorPos(&pt);
  msg.hwnd = hToolTip;
  msg.message = TTM_RELAYEVENT;
  msg.wParam = 0;
  msg.lParam = 0;
  msg.time = 0;
  msg.pt = pt;
  SendMessage(hToolTip, TTM_RELAYEVENT, 0, &msg);
  break;

Das ist natürlich völliger Blödfug, weil message die Nachricht ist, die weitergeleitet wird!

Ungeprüfter Code:

if (message>=WM_MOUSEFIRST && message<=WM_MOUSELAST)
{  MSG msg;
  msg.hwnd = hWnd;
  msg.message = message;
  msg.wParam = wParam;
  msg.lParam = lParam;
  msg.time = GetTickCount();
  GetCursorPos(&msg.pt);
  SendMessage(hToolTip, TTM_RELAYEVENT, 0, &msg);
}

Stimmt, ich wusste nicht, was ich mit der msg machen sollte und habe gar nicht daran gedacht, dass man die Nachricht weiterleiten muss.

Ich will keiner sein, der um Hilfe bittet und den Helfenden dann auf Schönheitsfehler aufmerksam macht, aber man muss ja das msg.hwnd gleich dem Fenster, das das Tooltip erhalten soll, setzen

"Wie... Woher weiß ich denn, was ich dann im Parent- und was im Child-Loop abfangen muss?"
Damit wollte ich fragen, woher ich denn weiß, dass ich einen Klick auf ein static Control im Hauptfenster abfangen muss, aber WM_MOUSEMOVE z.B. im Loop des gesubclassten Controls...
Leider weiß ich es immer noch nicht

PS: Wie schaffe ich es denn, dass sich die Position des Tooltips immer wieder aktualisiert, wenn man die Maus bewegt?

Vielen Dank für eure Hilfe, da bisher alles soweit klappt!!

Martin Richter

peteur schrieb:

Stimmt, ich wusste nicht, was ich mit der msg machen sollte und habe gar nicht daran gedacht, dass man die Nachricht weiterleiten muss.

Wenn Du die MSDN zu den Tooltips lesen würdest, dann wüsstest Du das.

Ich will keiner sein, der um Hilfe bittet und den Helfenden dann auf Schönheitsfehler aufmerksam macht, aber man muss ja das msg.hwnd gleich dem Fenster, das das Tooltip erhalten soll, setzen

Typischer C++ Fehler. Copy & Paste & Programer - Fehler.
Habe ich eben korrigiert.

"Wie... Woher weiß ich denn, was ich dann im Parent- und was im Child-Loop abfangen muss?"
Damit wollte ich fragen, woher ich denn weiß, dass ich einen Klick auf ein static Control im Hauptfenster abfangen muss, aber WM_MOUSEMOVE z.B. im Loop des gesubclassten Controls...
Leider weiß ich es immer noch nicht

Hä?
Ich verstehe immer noch nicht was Du meinst. Es gibt keine Child-Loop und Parent-Loop! Was meinst Du bitte damit. Es gibt Nachrichten für dieses und jenes Fenster. Aber Message-Loops hast Du immer nur eine (im Normalfall).
Du musst die Nachrichten des Fenster weiterleiten, auf dass sich das Tooltipp bezieht. Bzw. die des Parent. Siehe MSDN.

BTW: Arbeite nur mit der suibclass Verison in der WinAPI.
Ansonsten nimm die MFC und Du hast kein Problem mit dem Kram...

PS: Wie schaffe ich es denn, dass sich die Position des Tooltips immer wieder aktualisiert, wenn man die Maus bewegt?

Gar nicht. Tooltipps aktualisieren niemals ihre Position. Außer sie verschwinden und werden neu angezeigt. Auch das steht in der MSDN Doku!

Hä?
Ich verstehe immer noch nicht was Du meinst. Es gibt keine Child-Loop und Parent-Loop! Was meinst Du bitte damit. Es gibt Nachrichten für dieses und jenes Fenster. Aber Message-Loops hast Du immer nur eine (im Normalfall).
Du musst die Nachrichten des Fenster weiterleiten, auf dass sich das Tooltipp bezieht. Bzw. die des Parent. Siehe MSDN.

Das soll nicht auf die Tooltips bezogen sein.
Um die Tooltips auf einem statischen Control über SendMessage und WM_MOUSEMOVE anzeigen zu lassen, muss man dieses ja subclassen.
SS_NOTIFY muss doch auch eingestellt sein, oder?
Im Subclass-loop kann man nun also WM_MOUSEMOVE abfangen.
Wenn man jetzt noch z.B. Klicks abfangen will, geht das aber nicht mit WM_COMMAND im Subclass-loop, sondern in dem Hauptfenster-loop, warum ist das so zwiegespalten und woher weiß ich, welche Nachricht ich wo abfangen muss?

Martin Richter

peteur schrieb:

Um die Tooltips auf einem statischen Control über SendMessage und WM_MOUSEMOVE anzeigen zu lassen, muss man dieses ja subclassen.

Nö. Wenn man das Tooltip seinen Job machen lässt muss man das nicht.

SS_NOTIFY muss doch auch eingestellt sein, oder?

Aber sicher!

Im Subclass-loop kann man nun also WM_MOUSEMOVE abfangen.
Wenn man jetzt noch z.B. Klicks abfangen will, geht das aber nicht mit WM_COMMAND im Subclass-loop, sondern in dem Hauptfenster-loop, warum ist das so zwiegespalten und woher weiß ich, welche Nachricht ich wo abfangen muss?

Was soll das mit einer Subclass-Loop? Redest Du von der WndProc?
Ich verstehe immer noch nichts...

Schau Dir mal bitte einfach in der MSDN die einleitenden Kapitel zu Tooltips an. Da wird das doch ausgibigst mit Samples dargelegt.

Ne, das ist generell auf die Nachrichten bezogen..

Man hat ein Fenster mit einem Messageloop und dazu ein static Control, das mit 'Hallo' beschriftet ist.

Will man nun die Klicks darauf abfangen, muss man diesem statischen Control die Eigenschaft SS_NOTIFY geben und im Loop des Fensters die Nachricht WM_COMMAND mit dem static Control als wParam abfangen.

Will man aber WM_MOUSEMOVE abfangen, so muss man das static Control erst subclassen und in dem neuen Messageloop des static Controls dieses tun,
da die Nachricht im messageloop des Fensters nicht kommt.

Warum kriegt man WM_COMMAND im Loop des Fensters, aber um WM_MOUSEMOVE abzufangen muss man das static Control subclassen?

Wenn das gesubclasset Fenster, in deinem Fall das Static Control eine WM_MOUSEMOVE erhält wird nach der Tooltip Delaytime das Tooltipfenster angezeigt, hierzu benutzt du z.B. TTM_GETTOOLINFO, TTM_UPDATETIPTEXT, und TTM_TRACKPOSITION, wenn die Maus die Controll verlässt kannst du WM_MOUSELEAVE abfangen und per TTM_POP das Tooltipfenster verschwinden lassen.

Ich denke mal wenn du nun nach all den obengenannten Nachrichten googlest, wird du auf brauchbare Beispielcodes stossen.

Nachtrag:
Achso ja du brauchst kein WM_COMMAND und auch keinen SS_NOTIFY Style, da du das ganze Tooltipgedöns ja nun von Hand löst und nicht auf die vorgefertigeten Winapifunktionen zur Tooltipdarstellung, wie sie z.B. eine Toolbar bereitstellt, zurückgreiffst. Das ist meiner Meinaung nach sowieso besser, da du das so erzeugte Tooltipfenster auf alle Childfenster in deinem Programm anwenden kannst, du musst nur jeweils diese Fenster subclassen.

Danke!, nur...
War das nun auf meine beiden letzten Posts bezogen, oder auf vorherige?

Da die beiden letzten eigentlich gar nichts mehr mit den Tooltips zu tun haben...
Ich meine das ganz generell.
Also wo man welche Nachrichten abfängt und wieso da.
Beispiel:

WM_COMMAND im Loop des Fensters, das das Control inne hat
WM_SETCURSOR im Loop des gesubclassten Controls
Wieso ist das so, und woher weiß man das?

Martin Richter

@peteur: Ich weiß immer noch nicht was Du mit Loop meinst.
Ich vermute stark, Du meinst die WndProc. Dann rede auch davon und nciht von Loop!

- WM_COMMAND gehört zu den Notifications die zu der Funktionsweise eines Fensters gehören und dienen eben der Benachrichtigung des Fensters.
- Nachrichten wie WM_SETCURSOR, WM_MOUSEMOVE etc. gehören zu den Inputut-Nachrichten, die jedes Fenster nach eigener Funktionsweise selbst bearbeitet.
- Woher weiß man das?
Indem man die Doku der Nachricht liest MSDN.
BTW: Die wenigsten Nachrichten werden an das Parent gesendet. Das sind höchstens WM_COMMAND und WM_NOTOFY und noch einige wenige (unwichtige) andere.
Du kannst also i.A. davon ausgehen, dass 98% aller Nachrichten an das Fenster selbst gehen.