[lazarus] Has message handler stuff been implemented yet???

[Michael A. Hess]

Michael Van Canneyt wrote:
> 
> The point is that under Windows you have message functions.
> 
> Procedure DoKey (...) message WM_KEyCLICK;
> For such a procedure, special RTTI is generated.
> 
> All messages for an object come to 1 central procedure, which then
> calls dispatch (a method from TObject) which looks through the RTTI to
> see if there is a handler for the message registered. If so it is
> called. Thus, a Windows message arrives at the procedure you
> registered.

Of course I understand all of this I just didn't see how this related to
Linux or using GTK.
 
> Gtk has also messages, but they are strings, hence the possibility
> Procedure DoKey ( ) message 'string';
> Likewise, there is now a procedure DispatchStr() which takes a string
> as and argument (the signal name) and looks in the RTTI to see if
> there is a handler registered for the given signal name.

Ahhhhhh. There is the missing key. You never mentioned that the
DispatchStr function was there.
 
> A problem with this is that GTK is not object oriented, but does allow
> to pass data to the signal call. This means that you must put a
> pointer to 'self' in this data, and that 'self' must be loaded into
> the object when the function gets called: hence the above syntax.
> 
> So the above syntax is a mixture of 2 things: allowing string-type
> messages, and allowing calls from Non-OOP toolkits to OOP objects.
> 
> I don't know if GTK supports a 'all-purpose' signal handler; i.e. a
> signal handler that is called for any type of signal, but with
> additionally the signal as an option;

Not that I am aware of but that is more or less what I was trying to
write to use with lazarus and the fcl. That was why I was interested in
getting a better handle on what exactly has been implemented with the
message handler.
  
> I hope this is clear :(

It sure is! I just need the connection between the message 'signal' and
the fact that the DispatchStr function existed.

-- 
==== Programming my first best destiny! ====

Michael A. Hess      Miracle Concepts, Inc.
mhess at miraclec.com   http://www.miraclec.com