Re: [java-gnome-hackers] gnome conflicts with gtkentry

[Tom B. <Tom...@Su...>]

I'm fairly confident that the handle is bogus.  Not calling getString
may "fix" the problem, but only in that you aren't asking GTK to use a
bad handle, rather than fixing the cause of the bad handle.  One thing
I've learned over the years is how consistently I can be wrong, however.

Try using using memset to initialize the alloca buffer in jg_signal_cb
(0xca is a good value if you use a debugger, as pointers with that value
can't be dereferenced).  Using memset is an old trick for finding used
by not initialized memory -- a related trick is to memset freed memory
with a different but equally undereferencable value such as 0xba.  If
you want to be more sophisticated, paint the memory with words such as
"dead", "face", etc.  If possible, use a Unix-based system since Windows
allows dereferencing of non-aligned pointers, so you are more likely to
get a bad memory area that survives this test.

Tom

On Fri, 2003-04-11 at 12:21, Mark Howard wrote:
> On Tue, 2003-04-08 at 23:51, Tom Ball wrote:
> > it fails in EventKey.getString with a bogus eventkey handle.
> Are you sure it's bogus. The location certainly seems as vaild as the
> others. Commenting out the call to the native getString (in
> gdk.EventKey.getString) "fixes" the problems for me. 
> 
> The following is printed in the docs for the string field of GdkEventKey
> - perhaps we shouldn't be using GdkEventKey.string:
> 
> a string containing the an approximation of the text that would result
> from this keypress. The only correct way to handle text input of text is
> using input methods (see GtkIMContext), so this field is deprecated and
> should never be used. (gdk_unicode_to_keyval() provides a non-deprecated
> way of getting an approximate translation for a key.) The string is
> encoded in the encoding of the current locale (Note: this for backwards
> compatibility: strings in GTK+ and GDK are typically in UTF-8.) and
> NUL-terminated. In some cases, the translation of the key code will be a
> single NUL byte, in which case looking at length is necessary to
> distinguish it from the an empty translation.
-- 
Tom Ball <Tom...@Su...>