[Gtk-sharp-list] System.InvalidCastException from generated code

[Martin Willemoes Hansen]

On Mon, 2004-01-26 at 17:53, Mike Kestner wrote:
> On Mon, 2004-01-26 at 07:05, Martin Willemoes Hansen wrote:
> 
> > > Looking into the code, i found that the generator made the code:
> > > 
> > > 
> > > > 		public Gtk.SourceMarker CreateMarker(string name, string type, Gtk.TextIter where) {
> > > > 			IntPtr raw_ret = gtk_source_buffer_create_marker(Handle, name, type, ref where);
> > > > 			Gtk.SourceMarker ret = (Gtk.SourceMarker) GLib.Object.GetObject(raw_ret);
> > > > 			return ret;
> > > > 		}
> > 
> > try changing the code to be like this:
> > Gtk.SourceMarker ret = new Gtk.SourceMarker (raw_ret);
> 
> Not a good idea.  If you do this, you will end up with two or more
> wrappers pointing to the same native object, but only holding one native
> ref to the object.  When one of those wrappers gets GC'd, all your other
> wrappers are hosed.  It's going to bite you eventually, and it will be
> one of those almost impossible to debug problems, especially for
> somebody who doesn't know that you short-circuited the GetObject
> mechanism with custom code.

Heh okay.

> > > I think the problem comes from the folowing C code:
> > > 
> > > 
> > > >  33             GType 
> > > >  34             gtk_source_marker_get_type (void)
> > > >  35             {
> > > >  36             	static GType our_type = 0;
> > > >  37             
> > > >  38             	/* this function's solely purpose is to allow us to later
> > > >  39             	 * derive GtkSourceMarker from other base object and not break
> > > >  40             	 * ABI compatibility (since this way the type is resolved at
> > > >  41             	 * runtime) */
> > > >  42             	if (!our_type) {
> > > >  43				our_type = GTK_TYPE_TEXT_MARK;
> > > 
> > > It seems that Gtk# is confused as to the type of the object. What would
> > > be the best way to fix this?
> 
> Ben and I talked about this on IRC last night, and I advised him to file
> a bug against SourceView for subclassing objects without registering a
> new GType for the object.  There is no way a language binding can
> properly introspect a GObject type that's coded in this manner.

Yes, sounds like an idea, ill try to file som bug reports about these
issues, got some in DiaCanvas# too.
-- 
Martin Willemoes Hansen

--------------------------------------------------------
E-Mail	mwh@sysrq.dk	Website	mwh.sysrq.dk
IRC     MWH, freenode.net
--------------------------------------------------------