Bug in FOX related to composed characters and proposed patch

[roland65]

Hi there,

some weeks ago, I sent here a message where I described a bug related to
composed characters and XIM inputs. These characters are frequently used
for example in french (ex: â ô ), in german (to do the umlaut like in ü
ä ¶ etc.) and other languages.

For these characters to be correctly input in FOX application, the FOX
library must be compiled with the --with-xim configure option.

In FOX 1.6.36 and 1.7.19, compiled with the --with-xim option, entering
composed characters *only* works when the mouse pointer (caution : the
mouse pointer, not the input cursor) lies within the text field that has
the focus. Otherwise, if the mouse pointer is elsewhere in the window,
it is not possible to input characters like â ä ü û¶, etc. This can be
easily checked with adie : write a text and move the mouse pointer
outside the adie window. Then entering composed characters don't work
anymore.

After some (deep) investigations, I finally found where the problem is
and fixed the bug. I attached here a patch for the FXApp.cpp class of
FOX 1.6.36.

I succesfully tested this patch on the following Linux systems : Debian
Lenny (stable), latest Ubuntu, Mandriva 2009 but I didn't test it on
Windows.

Hope this post could help to definitely fix this annoying bug.

Best regards,
Roland

--
X File Explorer http://roland65.free.fr/xfe
Toutes Choses http://roland65.free.fr/ttc

*** FXApp.cpp.orig 2009-05-07 16:22:10.000000000 +0200
--- FXApp.cpp 2009-05-07 16:23:05.000000000 +0200
***************
*** 2021,2027 ****
    XNextEvent((Display*)display,&ev);
 
    // Filter event through input method context, if any
!   if(xim && XFilterEvent(&ev,None)) return false;
 
    // Save expose events for later...
    if(ev.xany.type==Expose || ev.xany.type==GraphicsExpose){
--- 2021,2029 ----
    XNextEvent((Display*)display,&ev);
 
    // Filter event through input method context, if any
!   FXWindow* focuswin;
!   focuswin=getFocusWindow();
!   if (xim && focuswin && XFilterEvent(&ev,(Window)focuswin->id())) return false;
 
    // Save expose events for later...
    if(ev.xany.type==Expose || ev.xany.type==GraphicsExpose){

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Monday 18 May 2009, Roland Baudin wrote:

> Hi there,
>
> some weeks ago, I sent here a message where I described a bug related to
> composed characters and XIM inputs. These characters are frequently used
> for example in french (ex: â ô ), in german (to do the umlaut like in ü
> ä ¶ etc.) and other languages.
>
> For these characters to be correctly input in FOX application, the FOX
> library must be compiled with the --with-xim configure option.
>
> In FOX 1.6.36 and 1.7.19, compiled with the --with-xim option, entering
> composed characters *only* works when the mouse pointer (caution : the
> mouse pointer, not the input cursor) lies within the text field that has
> the focus. Otherwise, if the mouse pointer is elsewhere in the window,
> it is not possible to input characters like â ä ü û¶, etc. This can be
> easily checked with adie : write a text and move the mouse pointer
> outside the adie window. Then entering composed characters don't work
> anymore.
>
> After some (deep) investigations, I finally found where the problem is
> and fixed the bug. I attached here a patch for the FXApp.cpp class of
> FOX 1.6.36.
>
> I succesfully tested this patch on the following Linux systems : Debian
> Lenny (stable), latest Ubuntu, Mandriva 2009 but I didn't test it on
> Windows.
>
> Hope this post could help to definitely fix this annoying bug.

Thanks,

I assume that the little code segment:

      // Keyboard
      case KeyPress:
#ifndef NO_XIM
        focuswin=getFocusWindow();
        if((ev.xkey.keycode!=0) && focuswin && focuswin->getComposeContext()){
          Window w;
          XGetICValues((XIC)focuswin->getComposeContext()->id(),XNFocusWindow,&w,NULL);
          if((focuswin->id()!=w) && XFilterEvent(&ev,(Window)focuswin->id())){
            return true;
            }
          }
#endif


will need to be removed in that case, right?  Otherwise stuff gets filtered twice....


        - Jeroen

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users