Ola Antonio,
Mucho gracias. I know what you mean by "taking so long". I do that all the
time too, so don't worry about it.
I almost forgot about this issue, but since then I've did some more research
and as a result, this has become my Windows programming philosophy:
Windows is native to UTF-16, not UTF-8 or UTF-GB (GB18035)
UTF-8 and UTF-GB are both ASCII/ANSI compatible, so they can be substituted in
most cases for ASCII functions
EVERYTHING that Unicode evangelists claim as a benefit for UTF-8, is also THE
SAME EXACT BENEFIT that UTF-GB offers, and because UTF-GB is legacy compatible
for Chinese, UTF-GB should always be promoted as the official Unicode encoding
of choice. To not do so can only be explained by a petty racist bias instead
of sound logic
Windows has a "multibyte" conversion function for UTF-8/UTF-GB, so while it
over-complicates things a little, it isn't hopelessly over-complicated,
probably adding about an extra eight lines of code whenever needed (like it is
for filenames).
Speaking of filenames, path lengths will be limited to 256 bytes unless you
use the "\\?\" prefix
The relevant Window API functions for those who are interested in having TRULY
international applications is:
MultiByteToWideChar()
WideCharToMultiByte()
WideCharToMultiByte()
I don't like it, but I most certainly can easily live with it.
Signed,
Andres
PS -- The problem with certain overlapping characters was due to the wrong DPI
being set for my monitor. As usual, it was a simple problem that was not at
all easy to find. The lesson learned is not all display monitors should
default to 96dpi, so all you people out there with 2560x1600 monitors out
there, be warned!
On 2020-05-01 at 7:27 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
Hi,
Sorry taking so long to get back to this.
I run some tests here and it seems to be working now:
This was in Windows 10 with visual styles enabled.
Here is in Windows 7 with visual styles enabled:
And Windows 7 using Classic Theme:
All build from latest SVN. Maybe something changed that fixed this. But
anyway it seems to be something in the native system. We don't have much
control over that inside an IupText.
Best,
Scuri
Em qui., 6 de fev. de 2020 às 16:25, Antonio Scuri <antonio.sc...@gmail.com>
escreveu:
Ok got it
Em qui, 6 de fev de 2020 11:54, Andrew Robinson <arobinso...@cox.net>
escreveu:
See attached
On 2020-02-06 at 8:51 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
Please send me a small text file with the string. Next week I'll be back to
work and check this.
Best,
Scuri
Em qui, 6 de fev de 2020 10:44, Andrew Robinson <arobinso...@cox.net>
escreveu:
No problemo,
The context was: IupSetStrAttribute(txtAsmCode,'VALUE',pCodeArray) where
txtAsmCode is a pointer to the multiline textbox control.
Regards,
Andres
On 2020-02-06 at 7:37 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
Hi,
I need more information about the context when the problem occurs.
Were you typing, or setting the VALUE attribute? Or pasting from clipboard?
Best,
Scuri
Em qui, 6 de fev de 2020 09:09, Andrew Robinson <arobinso...@cox.net>
escreveu:
Hello Antonio,
I just want to remind you that IUP still doesn't appear to support UTF-8
properly in textboxes, as evidenced by the screen capture below of the
right-pointer arrow (➔ U+279c) overlapping the characters u in "u8" and the
character $ in "$DstStr"
Regards,
Andrew
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
