Ich erstelle ein Fenster ToolTip und füge Tools hinzu mit den Flaggen TTF_IDISHWND | TTF_SUBCLASS. (c ++, win32)
Ich habe eine Manifest-Datei, so dass mein Programm die neuen WindowsXP-Themen verwendet (comctrl32 Version 6).
Wenn ich mit dem Mauszeiger über ein registriertes Werkzeug fahre, wird der Tipp angezeigt.
Gut.
Wenn ich mit der Maus klicke, verschwindet die Spitze.
Ok.
Allerdings weg vom Werkzeug und zurück
lässt den Tipp nicht wieder erscheinen. Ich muss über ein anderes Werkzeug fahren
und dann komm zurück zu meinem Werkzeug, um den Tipp zurück zu bekommen.
Wenn ich meine Manifest-Datei entferne (um die ältere Nicht-XP-Komponente 32 zu verwenden), wird die Problem verschwindet.
Nach einigen Experimenten entdeckte ich die folgenden Unterschiede zwischen ToolTips in Comctl32 Version 5 (alt) und Comctl32 Version 6 (neu):
Neue TTF_TRANSPARENT-QuickInfos (wenn sie vor Ort verwendet werden) werden tatsächlich zurückgegeben HTCLIENT von WM_NCITTEST, wenn eine Maustaste gedrückt ist, also bekommen WM_LBUTTONDOWN und stehlen den Fokus für einen Moment vor dem Verschwinden. Dies bewirkt Der Rand der Anwendung blinkt.
Alte TTF_TRANSPARENT QuickInfos geben immer HTTRANSPARENT von WM_NCHITTEST zurück. und deshalb niemals WM_LBUTTONDOWN selbst erhalten und niemals den Fokus stehlen. (Dies scheint nur ästhetisch zu sein, kann aber den nächsten Punkt beeinflussen ...)
Neue QuickInfos scheinen nach einem Mausklick keine WM_TIMER-Ereignisse zu erhalten, und Nehmen Sie nur (einige) Timer-Ereignisse nach der Deaktivierung wieder auf reaktiviert. Daher zeigen sie ihr Spitzenfenster nach einer Maus nicht erneut an klicken und loslassen.
Alte ToolTips erhalten eine WM_TIMER-Nachricht, sobald die Maus erneut bewegt wird Nach dem Klicken / Loslassen sind sie bereit, ihren Tipp erneut anzuzeigen.
Also musste ich als eine comtyl32 Workaround:
Unterklasse des TOOLTIPS_CLASS-Fensters und immer HTTRANSPARENT zurückgeben WM_NCHITTEST, wenn das Tool nach Transparenz gefragt hat.
Vermeiden Sie die Verwendung von TTF_SUBCLASS und verarbeiten Sie lieber die Maus-Nachrichten selbst Ich könnte beim Empfang von WM_xBUTTONUP deaktivieren / reaktivieren.
Ich gehe davon aus, dass die Änderung im internen Verhalten darin besteht, die neuen "anklickbaren" Features in ToolTips wie Hyperlinks zu berücksichtigen, aber das Hover-Verhalten scheint damit gebrochen zu sein.
Kennt jemand eine bessere Lösung als meine Workaround-Unterklasse? Fehle ich einen anderen Punkt?
Sie sind nicht der Einzige, der Kompatibilitätsprobleme mit Tooltips zwischen diesen DLLs hat.
Ich habe auch nichts als Probleme mit den neuen Tooltips in den entsprechenden gemeinsamen Steuerelementen. Wir haben bereits mit Maus-Nachrichten herumgespielt und die Tipps aktiviert / deaktiviert, bevor wir das Manifest hinzugefügt und unsere Anwendung angetastet haben - es klingt also so, als ob Ihr Tun nicht zu verrückt ist.
Wir leben immer noch mit Problemen mit TTN_NEEDTEXT-Nachrichten, die ständig gesendet werden, wenn sich die Maus bewegt (nicht nur beim Schweben), Positionierungsproblemen mit großen Tipps (vielleicht nichts Neues) und ungeraden Unicode-Nachrichten anstelle der ANSI-Versionen (die ich irgendwann als Frage stellen möchte).
Ich weiß es nicht, aber das hört sich nach einem wirklich "harten" Problem an (in dem Sinne, dass alle realen Probleme wirklich hart sind). Ich wette, dass das zugrunde liegende Problem etwas mit der Einstellung des Fokus zu tun hat. Windows, die das manuell tun, sind böse und leiden im Allgemeinen unter allen möglichen Fehlern.