Thread: RE: [Java-gnome-developer] CVS: Problem with gdk_BaseObject.c and GTK_IS_OBJECT()
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-developer
|
From: Jeffrey M. <Jef...@Br...> - 2001-10-09 19:27:35
|
I have struggled with this issue for some time and as
yet haven't found a solution. I need to determine if
a void pointer is actually pointing to a GTK type. All
macros and methods in GTK assume this is the case
(like the GTK_IS_OBJECT macro below). Does anybody
have a suggestion?
-Jeff
>
> In CVS version, in other/gdk_BaseObject.c:
>
> jobject makeBaseObjectSubclass (JNIEnv *env, jclass cls, void *peer)
> {
> if (peer == NULL)
> return NULL;
> else if (GTK_IS_OBJECT(peer))
> return makeBaseObjectClass(env, peer);
> else {
> jobject result = (*env)->AllocObject (env, cls);
> jlong result_jl;
>
> *(void **) &result_jl = peer;
> (*env)->SetLongField (env, result, nativepeerFid, result_jl);
> return result;
> }
> }
>
> The GTK_IS_OBJECT is a problem, if you try to create any
> object not based
> on Gtk, like GdkGC:
>
> xx = new GdkGC(yy);
>
> leads to:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x41383ed6 in makeBaseObjectSubclass (env=0x400887d4, cls=0x6,
> peer=0x81244f8)
> at other/gdk_BaseObject.c:70
> 70 else if (GTK_IS_OBJECT(peer))
>
> This, of course happens because "peer" in this context is not a Gtk
> object, but instead a GdkWindow, which isn't representable in the Gtk
> object system:
>
> (gdb) p *(GdkGC*)peer
> $14 = {dummy_var = 1701080693}
> (gdb) p *((GtkObject*)peer)
> $15 = {klass = 0x65646e75, flags = 135415064, ref_count = 135220712,
> object_data = 0x1}
> (gdb) p *((GtkObject*)peer)->klass
> Cannot access memory at address 0x65646e75
>
> In noticed the GTK_IS_OBJECT was added in version 1.5 (of that file).
> Apparently this hasn't been noticed since the test and sample programs
> don't use GdkGC directly at all..
>
> --
> sa...@ik... I have become death,
> destroyer of the worlds.
>
>
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>
|
|
From: Jeffrey M. <Jef...@Br...> - 2001-10-09 19:42:10
|
What I have is a pointer to the underlying peer which could be a GTK type, a GNOME type or a GDK type. Since the pointer to the peer is stored the same in each case it is stored as a void pointer. > Do you really need to pass void pointers around? > > John Leuner > |
|
From: Jeffrey M. <Jef...@Br...> - 2001-10-10 20:20:29
|
What I ultimately did to resolve this was change all of the GDK types in gdk.defs to be of type define-boxed which creates the shell java class with the appropriate accessors and methods but initializes the object without a check for the GTK type. This update is in CVS if you want to check it out. Let me know if this works for you. -Jeff This seems like a simple approach that will work. I think I will try it this evening. Wow - thanks!! -Jeff > > Of course there is no generic way to test that -- we could put all GTK > objects into a hashtable and check them from there.. but > that's not really > an option. > > However, the caller to makeBaseObjectSubclass routine always knows the > type of the 'peer' argument, eg. whether it is a GTK or > non-GTK object. > Thus, we could remove the GTK_IS_OBJECT test from > makeBaseObjectSubclass, > add a new routine makeGtkBaseObjectSubclass, which would have the > GTK_IS_OBJECT test, and modify the code generator to use the > GTK routine > version when it knows that the underlying object (for which > it is being > called) is a GTK (or Gnome) object, and not some other (glib, gdk). > > -- > sa...@ik... I have become death, > destroyer of the worlds. > > > |
|
From: Santeri P. <sa...@ik...> - 2001-10-09 19:34:56
|
On Tue, 9 Oct 2001, Jeffrey Morgan wrote: > I have struggled with this issue for some time and as yet haven't > found a solution. I need to determine if a void pointer is actually > pointing to a GTK type. All macros and methods in GTK assume this is > the case (like the GTK_IS_OBJECT macro below). Does anybody have a > suggestion? Of course there is no generic way to test that -- we could put all GTK objects into a hashtable and check them from there.. but that's not really an option. However, the caller to makeBaseObjectSubclass routine always knows the type of the 'peer' argument, eg. whether it is a GTK or non-GTK object. Thus, we could remove the GTK_IS_OBJECT test from makeBaseObjectSubclass, add a new routine makeGtkBaseObjectSubclass, which would have the GTK_IS_OBJECT test, and modify the code generator to use the GTK routine version when it knows that the underlying object (for which it is being called) is a GTK (or Gnome) object, and not some other (glib, gdk). -- sa...@ik... I have become death, destroyer of the worlds. |
|
From: John L. <je...@pi...> - 2001-10-09 19:39:16
|
> I have struggled with this issue for some time and as
> yet haven't found a solution. I need to determine if
> a void pointer is actually pointing to a GTK type. All
> macros and methods in GTK assume this is the case
> (like the GTK_IS_OBJECT macro below). Does anybody
> have a suggestion?
Do you really need to pass void pointers around?
John Leuner
> >
> > In CVS version, in other/gdk_BaseObject.c:
> >
> > jobject makeBaseObjectSubclass (JNIEnv *env, jclass cls, void *peer)
> > {
> > if (peer == NULL)
> > return NULL;
> > else if (GTK_IS_OBJECT(peer))
> > return makeBaseObjectClass(env, peer);
> > else {
> > jobject result = (*env)->AllocObject (env, cls);
> > jlong result_jl;
> >
> > *(void **) &result_jl = peer;
> > (*env)->SetLongField (env, result, nativepeerFid, result_jl);
> > return result;
> > }
> > }
> >
> > The GTK_IS_OBJECT is a problem, if you try to create any
> > object not based
> > on Gtk, like GdkGC:
> >
> > xx = new GdkGC(yy);
> >
> > leads to:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x41383ed6 in makeBaseObjectSubclass (env=0x400887d4, cls=0x6,
> > peer=0x81244f8)
> > at other/gdk_BaseObject.c:70
> > 70 else if (GTK_IS_OBJECT(peer))
> >
> > This, of course happens because "peer" in this context is not a Gtk
> > object, but instead a GdkWindow, which isn't representable in the Gtk
> > object system:
> >
> > (gdb) p *(GdkGC*)peer
> > $14 = {dummy_var = 1701080693}
> > (gdb) p *((GtkObject*)peer)
> > $15 = {klass = 0x65646e75, flags = 135415064, ref_count = 135220712,
> > object_data = 0x1}
> > (gdb) p *((GtkObject*)peer)->klass
> > Cannot access memory at address 0x65646e75
> >
> > In noticed the GTK_IS_OBJECT was added in version 1.5 (of that file).
> > Apparently this hasn't been noticed since the test and sample programs
> > don't use GdkGC directly at all..
> >
> > --
> > sa...@ik... I have become death,
> > destroyer of the worlds.
> >
> >
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> >
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X