I found another XmString thing to fix for WIDECHAR support, which we use and are testing now.
In XmString.c, the function XmStringGetNextSegment...
 
Before:

if (text)
{

    *text = XtNewString(context->text);
}

After:

if (text)
{
    /* XXX May not be the safest way to determine that string is Unicode */

    if (strncasecmp(context->charset, "iso10646", 8) == 0)
    {
        int size = (_ucstrlen(context->text) + 1) * 2;
        void* ucstr = XtMalloc(size);
        memcpy(ucstr, context->text, size);
        *text = (
char*)ucstr;
    }
    else
    {
        *text = XtNewString(context->text);
    }
}

To do this "correctly" _XmStringGetNextSegment would have to be modified to return something else telling us what the component type of context->text is.  However, I don't know if that function's parameter list is set in stone or if it could be modified.
 
After this fix (plus the ones I submitted earlier), XmString appears to correctly handle WIDECHAR text, at least for the cases where we use it in our software. 
 
 -- Dave Williss
------
Meddle not in the affairs of dragons,
   for you are crunchy and taste good with catsup
 
----- Original Message -----
Sent: Friday, May 14, 2004 1:06 AM
Subject: RE: [Lesstif] Fixes to XmString.c

> I have several fixes to XmString.c to submit. What would be the
> best way to go about doing it?

You can send them to me in private E-mail, or submit them as a
bug or patch via the SourceForge trackers, or send them to
the list.
 
Sending them to me is just fine in this case.
 
The format is actually an important one. Context diffs would be
much better than whole files. Use "diff -c" on the individual files
(diff -c RowColumn.c.orig RowColumn.c) if you still have the
original files next to your updated versions, or use
  cvs -z9 diff
on the whole directory if you changed it in a checkout from
(anonymous) CVS.
 
Danny

Reply via email to