Hi,

  Using the latest IUP version I just tested in systems:

Ububtu 15 GTK 3
Ububtu 12 GTK 2

  with global attribute UTF8MODE= Yes and No, in both systems.

  They all work ok. When UTF8MODE=No, the output is mangled because the
system locale is UTF-8, but using IupGetAttribute(ih, "VALUE") returns a
valid string.

  I used the iuptest application that is available in the IUP distribution.

  Sorry, I don't have a pure Debian here.

Best,
Scuri


On Mon, Sep 21, 2015 at 6:30 AM, "Jörg F. Wittenberger" <
joerg.wittenber...@softeyes.net> wrote:

> Am 20.09.2015 um 21:05 schrieb Antonio Scuri:
> >   Because of the console default locale. In Windows it is not UTF-8. In
> > modern Linux, at least in Ubuntu the default is UTF-8. So it should work.
> > I'll make a few tests here next week and let you know.
>
> I see.  Now this is a Debian/Testing here and the locale is configured
> to UTF-8.
>
> But as mentioned: it's not only on the debug output, the control itself
> ended up with the mangled content too.
>
> Best
>
> /Jörg
>
> >
> > Best,
> > Scuri
> >
> >
> > On Sat, Sep 19, 2015 at 7:13 AM, "Jörg F. Wittenberger" <
> > joerg.wittenber...@softeyes.net> wrote:
> >
> >> Am 18.09.2015 um 22:03 schrieb Antonio Scuri:
> >>>   I think that won't work. It will print garbage... Specially in
> Windows.
> >>
> >> Out of curiosity: why will it print garbage?
> >>
> >> (BTW: In the case at hand it's not Windows. As I noted: I've been able
> >> to bypass the issue.)
> >>
> >> The symptom was NOT exclusively seen in the printf debug output.  The
> >> same mangled string was displayed by the IupText control.
> >>
> >> Best
> >>
> >> /Jörg
> >>
> >>>
> >>> Best,
> >>> Scuri
> >>>
> >>>
> >>> On Fri, Sep 18, 2015 at 4:55 PM, "Jörg F. Wittenberger" <
> >>> joerg.wittenber...@softeyes.net> wrote:
> >>>
> >>>> Am 17.09.2015 um 02:34 schrieb Antonio Scuri:
> >>>>>   How are you checking this? Using a printf like output?
> >>>>
> >>>> Exactly.  Sitting in the action callback I fed the new_value pointer
> to
> >>>> printf(stderr, "SearchV: \"%s\"\n", new_value);
> >>>>
> >>>>
> >>>>>
> >>>>>   I couldn't reproduce the problem here.
> >>>>>
> >>>>> Best,
> >>>>> Scuri
> >>>>>
> >>>>>
> >>>>> On Thu, Aug 27, 2015 at 10:21 AM, Antonio Scuri <
> >>>> sc...@tecgraf.puc-rio.br>
> >>>>> wrote:
> >>>>>
> >>>>>>   ok I'll check that.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Scuri
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Aug 26, 2015 at 6:22 PM, "Jörg F. Wittenberger" <
> >>>>>> joerg.wittenber...@softeyes.net> wrote:
> >>>>>>
> >>>>>>> I'm trying to use the ACTION callback on a IupText.  The callback
> >>>>>>> receives wierd values for the 3rd (char* new_value) argument.
> >>>>>>>
> >>>>>>> Here what I get when I enter "merkwürdig":
> >>>>>>>
> >>>>>>> SearchV: "m"
> >>>>>>> SearchV: "me"
> >>>>>>> SearchV: "mer"
> >>>>>>> SearchV: "merk"
> >>>>>>> SearchV: "merkw"
> >>>>>>> SearchV: "merkwü"
> >>>>>>> SearchV: "merkw�r�"
> >>>>>>> SearchV: "merkwüdr"
> >>>>>>> SearchV: "merkwürid"
> >>>>>>> SearchV: "merkwürdgi"
> >>>>>>>
> >>>>>>> The "ü" character is first damaged, then restored.  Worse: from now
> >> on
> >>>>>>> the last two characters are always kept swapped.
> >>>>>>>
> >>>>>>> The problem worsens to total mess when I enter two UTF-8
> characters.
> >>>>>>>
> >>>>>>>
> >>>>>>> I've been able to work around the problem by ignoring the ACTION
> >>>>>>> callback and retrieving the current value in VALUECHANGED_CB.
> >>>>>>>
> >>>>>>> Just wanted to inform you about the issue.
> >>>>>>>
> >>>>>>> Best
> >>>>>>>
> >>>>>>> /Jörg
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
>
------------------------------------------------------------------------------
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

Reply via email to