DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2444 Version: 1.3-current This might be new with the UTF8 mods. I've traced it down to what appears to be a difference in the behavior of XUtf8LookupString() between the SGI and Linux. In Fl_x.cxx, it's after this call to XUtf8LookupString() that the buffer[0] gets 0x63 on SGI, and 0x03 on linux: ---- if (fl_xim_ic) { if (!filtered) { Status status; len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey, buffer, buffer_len, &keysym, &status); ---- On both platforms, XUtf8LookupString() is passed in an xevent.xkey structure that seems to have the same values going on both platforms for these values, and except for buffer[], the keysym and status return values are the same as well. Both platforms show these values: <CTRL> -- xkey.keycode=0x25 xkey.state=0x00 keysym=0xffe3 status=0x03 <C> -- xkey.keycode=0x26 xkey.state=0x04 keysym=0x0061 status=0x04 ..vs just hitting the 'C' key: <C> -- xkey.keycode=0x26 xkey.state=0x00 keysym=0x0061 status=0x04 ^^^^ So it seems like the linux box's XUtf8LookupString sees xkey.state being 0x04, and makes the buffer[] contain the CTRL-C, whereas the SGI ignores this, returning the 'c' character. Link: http://www.fltk.org/str.php?L2444 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
