RE: [gtk-list] Re: Signal and event management.

["Enric J." <rayder iname com>]

----------
> De: Havoc Pennington <rhpennin@midway.uchicago.edu>
> Fecha: jueves 3 de diciembre de 1998 20:08
> 
> See Tim's answer, or you can use the Gtk-- approach.

Yes Tim's answer are the nearest to a working solution :-), unfortunately
Signal_emit Api is still in development.
 
> This is what Gtk-- does, maybe it will help to understand the source: 
> 
> All widgets have an associated Class struct, that has a function for each
> signal or virtualized operation (not all of them are signals). Gtk-takes
> the normal contents of this struct, and saves it somewhere else. Then it
> installs its own custom functions which basically chain the signal out to
> the C++ object via a method called signal_name_impl(), which by default
> calls the original C function we saved, but can be overridden by user
> subclasses. 

This is just what I'm doing now, well maybe with some simplifications, but
essentially is taking a hook on default signal class handlers. This is what
I asked in my first message if it is a correct approach, it's not very
portable across Gtk versions, but it mostly works.
 
> This is all set up by a preprocessor which parses special "macros" like
> SIGNAL_SPEC() in the .gen_h files, and creates the necessary _impl
> method, replacement function to put in the Class (signal_name_callback), 
> and generates the struct where we will save the original C functions
> (Gtk_c_signals_Name). 

I see, very complex, and this way to do things is very C (C++) oriented, in
ObjectPascal I've no pre-processors, no Macros, no tremplates, btw thanks
for the info.
 
> The way to figure it out is to look at say widget.gen_h and then
> widget.h/widget.cc, to see what's generated.

I will take a look but now I see that this is not a valid approach for me.

Thanks very much.

Bye.... for now...

Enric
----------------------------------------------------
Microsoft does have a Year 2000 problem. We're it.