Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!imryrr.Eng.Sun.COM!elric
From: elric@imryrr.Eng.Sun.COM (Rick Heli)
Newsgroups: comp.windows.x
Subject: Re: XLookupString status argument nyi
Message-ID: <141981@sun.Eng.Sun.COM>
Date: 6 Sep 90 23:25:02 GMT
References: <2464@uwbull.uwbln.UUCP> <1990Sep5.232804.11515@wrl.dec.com>
Sender: news@sun.Eng.Sun.COM
Distribution: comp
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 25

In article <1990Sep5.232804.11515@wrl.dec.com> klee@wsl.dec.com writes:
>
>In article <2464@uwbull.uwbln.UUCP>, ckl@uwbln.UUCP (Christoph Kuenkel) writes:
>|> We were using Motif 1.0.n on a DECstation using DECs Xlib.  Composing
>|> diacritical characters such as german ``umlaut'' using the compose
>|> key worked just fine.  After porting that to a triton computer using
>|> the original Xr4 Xlib, the compose key did not work anymore. 
>
>While the Xlib spec does provide a hook for compose processing (the
>last argument in XLookupString), the X11R4 sample Xlib does not
>implement this.  DEC added compose processing to it's Xlib to support
>European keyboards.  As international support is pretty popular these
>days, other vendors may have done the same to their Xlibs.

As a matter of fact, Sun provides support for compose processing with
OpenWindows version 2.

Since vendor Xlib's are supporting this, it's important that applications
take care to either make sure the last argument to XLookupString() (a
pointer to an XComposeStatus) points to valid memory or be NULL.  Passing
in invalid pointers can cause memory trashing problems.

--
						Rick Heli
						Internet:  rheli@sun.COM