Window Procedure auf Methode umbiegen

[Eclipticon]

Hi,

ich moechte aus einem (nicht-visuellen) Objekt WM_HOTKEY abfangen und daher die Window Procedure auf eine Methode dieses Objekts umbiegen, um die Messages auszuwerten und ggf zu behandeln. Das ganze nach diesem Ansatz (Delphi):

http://www.delphidabbler.com/articles?article=1" onclick="window.open(this.href);return false;

Das scheitert aber immer bei

Code: Alles auswählen

// Create hidden window using WndMethod as window proc
 fHWnd := AllocateHWnd(WndMethod);

weil WndMethod einen Parameter verlangt.

Wie stelle ich das am besten an?

Danke

[Heinrich Wolf]

vielleicht

Code: Alles auswählen

{$ifdef fpc}
AllocateHWnd(@WndMethod);
{$else}
AllocateHWnd(WndMethod);
{$endif}

[Eclipticon]

Sorry, das hatte ich auch schon versucht:

Error: Incompatible type for arg no. 1: Got "<address of procedure(var TMessage) of object;Register>", expected "<procedure variable type of procedure(var TMessage) of object;Register>"

[Heinrich Wolf]

"type of" ist vielleicht der Weg zum Erfolg;
type tWndMethod = procedure(var TMessage) of object;
Schau doch mal in die LCL, wie's dort gemacht wird.

[Eclipticon]

Hmmm ... TWndMethod is ja schon entsprechend in Classes deklariert ...

[Heinrich Wolf]

Hmm. Ich hab jetzt mein gesamtes C:\Lazarus incl. fpc src durchsucht. Ich finde:
fpc\2.5.1\source\rtl\win32\classes.pp (41,10) function AllocateHWnd(Method: TWndMethod): HWND;
fpc\2.5.1\source\rtl\win32\classes.pp (36,3) TWndMethod = procedure(var msg : TMessage) of object;
Aber ich finde nichts, wo das verwendet wird.

Ähnlich finde ich:
lcl\controls.pp (222,3) TWndMethod = procedure(var TheMessage: TLMessage) of Object;
Aber in diesem Zusammenhang finde ich kein AllocateHWnd

[Socke]

In der Unit LCLIntf bzw. in den Widgetset-Klassen gibt es auch noch die Methode AllocateHWnd, die nimmt aber ein Argument vom Typ TLCLWndMethod, welches mit der Deklaration aus controls fast identisch ist.

Error: Incompatible type for arg no. 1: Got "<address of procedure(var TMessage) of object;Register>", expected "<procedure variable type of procedure(var TMessage) of object;Register>"

Da könnte folgender Quelltext helfen:

Code: Alles auswählen

var
  m: TWndMethod;
begin
  m := @WndMethod;
  AllocateHWnd(m);
end;

[mschnell]

Was genau meinst Du mit einem "nicht visellem Objekt" ?

Messages abfangen geht mit "procedure() .... message". Ich weiß nicht, welche Voraussetzungen genau das Objekt haben muss in dem das definiert wird. Ein Form muss es - glaube ich - nicht unbedingt sein. Es geht aber vermutlich nur in einer "Applikation" (mit GUI Anbindung, TTimer funktioniert) , nicht in einem "Programm" (Command-Line-Tool, TTimer funktioniert nicht).

-Michael

[Eclipticon]

Hi Socke,

In der Unit LCLIntf bzw. in den Widgetset-Klassen gibt es auch noch die Methode AllocateHWnd, die nimmt aber ein Argument vom Typ TLCLWndMethod, welches mit der Deklaration aus controls fast identisch ist.

LCLIntf.AllocateHWnd macht den Job perfekt, vielen Dank!

(Was soll man nun von dieser Redundanz halten?)

[Eclipticon]

Hi Michael,

Was genau meinst Du mit einem "nicht visellem Objekt" ?

Etwas, das von TObject und nicht von TComponent abgeleitet ist ...

Es geht aber vermutlich nur in einer "Applikation" (mit GUI Anbindung, TTimer funktioniert) , nicht in einem "Programm" (Command-Line-Tool, TTimer funktioniert nicht).

Sicher? Ich habe schon (unter Win32) ein Kommandozeilenprogramm geschrieben (abgeleitet von TCustomApplication), das zur Laufzeit erzeugte TTimer verwendet ... allerdings auch noch weitere LCL-Komponenten wie einen TNA Icon ...

[mschnell]

Dann wurde das entsprechende "visual" Zeug aus der LCL mit eingebunden. Ist unter Windows auch egal, weil Windows immer die API dafür zur Verfügung stellt. Unter Linux kann man aber "kleine" Systeme bauen, die keinen Grafik-Support bieten, also ohne GTK/QT und X-Server. Da würde ein "unechtes" comman-line-Programm, das das "visual" Zeugs aus der LCL einbindet, nicht laufen.

Wie wartet denn Dein Kommandozeilen-Programm darauf, dass ein TTimer-Event eintrifft ? "Echte" command-line Programme warten nicht, sondern beenden sich, sobald die Arbeit getan ist. Sie warten höchstens in einem blocking I/O. Dann warten sie aber nur auf genau eine Sache und laufen danach unverdrossen weiter. Auf zwei Sachen gleichzeitig warten geht nicht ohne besondere Tricks.

-Michael

[Socke]

Ist unter Windows auch egal, weil Windows immer die API dafür zur Verfügung stellt.

Zufällig weiß ich, dass man die Windows-Server-Editionen auch ohne grafische Oberfläche installieren kann -- auch wenn dies nicht die Regel darstellt.

"Echte" command-line Programme warten nicht, sondern beenden sich, sobald die Arbeit getan ist.

Es gibt auch noch die "unechten Kommandozeilenprogramme", die interaktiv arbeiten und ebenfalls eine grafische Oberfläche auf der Konsole (zum Beispiel mit ncurses) besitzten.

Das Problem bleibt: TTimer arbeitet immer über das Widgetset. Eigene Implementierungen können natürlich auch anders arbeiten (zum Beisipiel in einem Thread warten).

[mschnell]

Ist unter Windows auch egal, weil Windows immer die API dafür zur Verfügung stellt.

Zufällig weiß ich, dass man die Windows-Server-Editionen auch ohne grafische Oberfläche installieren kann -- auch wenn dies nicht die Regel darstellt.

Interessant. Ich frage mich, ob dann eine Verwendung die Grafik-API durch ein Programm zu einem Fehler führt oder einfach ignoriert wird. Und ob die API, die von TTimer verwendet wird (der unter Windows eine Message an das Main-Window schickt) funktioniert

"Echte" command-line Programme warten nicht, sondern beenden sich, sobald die Arbeit getan ist.

Es gibt auch noch die "unechten Kommandozeilenprogramme", die interaktiv arbeiten und ebenfalls eine grafische Oberfläche auf der Konsole (zum Beispiel mit ncurses) besitzten.

Kann ncurses Timer ?

Das Problem bleibt: TTimer arbeitet immer über das Widgetset. Eigene Implementierungen können natürlich auch anders arbeiten (zum Beisipiel in einem Thread warten).

Klar, so etwas gibt es nur (bisher) nicht bei Lazarus in der LCL (wohl aber bei MSEGUI). Die LCL müsste dafür einen "noGUI" Wídget Type bekommen (wäre durchaus machbar, habe ich versucht, ist aber vier Aufwand). Zusätzlich zum Timer braucht man auch noch Sachen wie TThread.Synvhronize, Application.QueuAsyncCall, und PostMessage.

-Michael