Op Wed, 9 May 2007, schreef Andrew Haines:
> Daniël Mantione wrote:
> >
> > Op Tue, 8 May 2007, schreef Andrew Haines:
> >
> >> The reason for this is, I want to trick gtk into thinking that a TObject
> >> is really a GObject. This is where the TypeID for GType's are stored. I
> >> know this won't work for most GObject's, but I am only implementing this
> >> for a GInterface which is looked up by the TypeID, so that is all I need.
> >>
> >> I've tested this and it is working. But what horrible things can happen?
> >
> > I think it is much better to use objects for this rather than classes. A
> > construction like this:
> >
> > type gobject=object
> > gobject_typeid:...;
> > end;
> >
> > gobject_child=object(gobject)
> > constructor init;
> > destructor done;virtual;
> > end;
> >
> > ... will exactly to what you want: the gobject_typeid is at offset
> > 0 while the size and vmt index are stored after that.
> >
>
> type
> TBaseObject=object
> FGObject: TGObject;
> end;
>
> TMyObject=object(TBaseObject)
> procedure MyProcedure; virtual; cdecl;
> end;
>
> This is working perfectly. I am letting gtk allocate the object's
> memory, then in the instance_init func that gtk calls I am running .Init
> for the object and voila! I have a real object that I can pass to gtk
> and use in my program.
I think this is an interresting way to talk to the gtk. I wonder how far
can go interfacing directly without adding wrappers. I.e. most GTK
function use a pointer to a GTK type as first parameter, which is binary
compatible with a self pointer...
Daniël
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
