Application.HideHint ändern

[ConnorMcLeod]

Hallo Kollegen,
vllt steh ich gerade fest aufm Schlauch, aber ... weshalb bringt D2010 einen E2089 bei

Delphi-Quellcode:

TMethod(Application.HideHint).Code := MyAppHideHint.Code;

?
Ich möchte die HideHint-Prozedur ändern, um zusätzlich selbst darauf reagieren zu können, wenn das HintFenster ausgeblendet wird.
Wie immer danke für alle Ideen ;-) + fg

[himitsu]

Weil der Compiler endlich mal schauler ist, als du. (früher wurde sowas einfach noch nicht bemängelt)

Es wird das Propert HideHint ausgelesen und du versuchst in der ausgelesenen

Delphi-Quellcode:

Kopie

dieses Records ein Feld zu ändern.
Und nein, es wird ausschließlich der Getter aufgerufen, da du ja einen bestehenden Wert teilweise ändern willst, aber es wird nacher nicht mehr per Setter zurückgespeichert.


[edit] HideHint ist eine Methode und dann noch nichtmal virtuell ... das kann so oder so garnicht funktionieren.

[ConnorMcLeod]

Stimmt, es ist eine Methode und kein Property.
Daher sollte der Cast auf TMethod funktionieren. Tut er aber nicht. Und das wundert mich, da ich auf diese Art öfter das Verhalten von Methoden ändere. Und dort geht das.

Das ist übrigens kein schmutziger Trick, sondern funktioniert mit den Bordmitteln ganz legal. Der Record TMethod ist für Zwecke wie diesen gemacht.

[virtual] käme dann zum Tragen, wenn ich [override] verwendete. Tu ich aber nicht, weil ich nicht kann, weil es nicht [virtual] ist :-) Sonst wäre das ganze Problem kein Problem.

[himitsu]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1290937)

Daher sollte der Cast auf TMethod funktionieren. Tut er aber nicht.

Ja, zum Auslesen und das funktioniert auch.
Also man kann die "Adresse" auslesen und z.B. casten oder an eine Event-Variable übergeben.

Und was mich nicht wundert: Man kann das natürlich nicht zurückschreiben oder ändern ... wohin auch?
Das geht maximal mit einem bösen Hook.


Seit XE, XE2 oder XE3 (k.A.) kann man man sich in virtuale Methoden auch mit einen Interceptor reinhängen.
TVirtualMethodInterceptor
Und vorher konnte man sich auch böswillig und manuell an der VMT zu schaffen machen.

[ConnorMcLeod]

Delphi-Quellcode:

var
  lpDummy: Pointer;
begin
  lpDummy := TMethod(Application.HideHint).Code;

funktioniert nicht und resultiert in:

Code:

[DCC Fehler] E2089 Ungültige Typumwandlung

[Bernhard Geyer]

In der TNTWare-Controls gibts doch Helperfunktionen um solche Hooks korrekt zu setzen.
Für Funktionen funktioniert es (z.B. ersetzen von Format-Befehl um unter D6 den Bufferfehler zu umgehen). Evtl. funktioniert das auch hier

[ConnorMcLeod]

Danke für den Tip, ich möchte möglichst ohne ZusatzTools auskommen.
Mein Weg wird wohl sein, eine eigene THintWindow-Klasse zu erstellen, dort ShouldHideHint zu überschreiben und mir darin selbst eine Message zu posten. :?

[himitsu]

Eventuell auch TApplicationEvents.OnMessage und auf WM_DESTROY des HintWindows reagieren.
Oder, da die HintWindows-Klasse eine TComponent ist, sich beim Anzeigen dranhängen (TComponent.FreeNotification).

Direkte Events/Messages, beim Ausblenden des Hints, hab ich auch nicht entdecken können.

[ConnorMcLeod]

Das hatte ich ausprobiert und mglw etwas übersehen, aber es scheint so, daß das Hintfenster nicht zerstört wird, sondern nur versteckt. Leider.

[himitsu]

WM_CLOSE, CM_VISIBLECHANGED usw.

[ConnorMcLeod]

Wie ich schon schrieb ... Message abfangen funkt leider nicht.

[Dalai]

Schau dir vielleicht mal die Units NativeHintWindow und FastCodePatch (bzw. Cromis.Detours) an. Beide ändern in Zusammenarbeit miteinander die Delphi-Hints in native und "patchen" dabei Application.HideHint.

MfG Dalai

[ConnorMcLeod]

Das sieht doch mal gut aus :thumb:
Daß dabei TApplication.HideHint als einzige Methode derart gepatcht werden muß bekräftigt mich in der Annahme, daß in diesem Fall die üblichen Mittel tatsächlich nicht ausreichen.
Danke sehr!

[himitsu]

Aber es ist letztendlich doch nur ein "Windows"?

Dann müsste es eigentlich viele Messages geben, welche von und an das Ding gehen. :gruebel:

[ConnorMcLeod]

IIUC ist es kein ausgewachsenes Fenster, sondern "nur" ein TWinControl. Ich vermute, daß Windoof ein Tooltip-Window erzeugt und Delphi das THintWindow (das zwar Window heißt, aber kein TCustomForm ist) darin einbaut um die Anzeige zu malen.

Es würde mich zwar akademisch interessieren, wie der Mechanismus tatsächlich abläuft, aber die Zeit dafür bezahlt niemand :-/

Ich bin momentan happy mit der eigenen THintWindow-Klasse und werde mglw den FastcodeAddressPatch verwenden, um applikationsweit nur eine einzige Prozedur zu haben, die dann mittels Interface verschiedene THintWindow-Klassen bedienen kann.

[himitsu]

Alles was Windows anzeigt, sind "Fenster" ... selbst ein TEdit (EDIT) oder ein TButton (BUTTON) sind nur Fenster, die in das große Top-Level-Fenster eingebettet sind.
Und jedes WinControl wird über Messages kontrolliert.

http://stackoverflow.com/questions/9...2-edit-control

[ConnorMcLeod]

Schon klar, deswegen waren die MessageHandler meine erste Idee; THintWindow wird offenbar dennoch anders behandelt. Schon mal selbst probiert?

[himitsu]

Delphi-Quellcode:

procedure TForm2.ApplicationEvents1Message(var Msg: tagMSG; var Handled: Boolean);
var
  C: TWinControl;
begin
  C := FindControl(Msg.hwnd);
  if C is HintWindowClass then begin
    Tag := Tag + 1;
    Caption := IntToStr(Tag);
  end;
end;

Hmmmmm, also entweder hostet Windows die HintWindows extern, was aber nicht gehen kann, denn irgendwo muß das WM_PAINT des HintWindows vorbeikommen, denn als ich zuletzt eine eigene Hint-Klasse schrieb, da ist das noch angekommen (in der Klasse).
Oder man muß auf irgendwas Anderes hören, oder Delphi fängt die HintMessages ab, bevor sie beim OnMessage vorbeikommen. :gruebel:

Delphi-Quellcode:

  THintWindow = class(TCustomControl)
  protected
    procedure Paint; override;
    procedure WMPrint(var Message: TMessage); message WM_PRINT;