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
Hi,
Sorry taking so long to get back to this.
I run some tests here and it seems to be working now:
[image: image.png]
This was in Windows 10 with visual styles enabled.
Here is in Windows 7 with visual styles enabled:
[image: image.png]
And Windows 7 using Classic Theme:
[imag
Ok got it
Em qui, 6 de fev de 2020 11:54, Andrew Robinson
escreveu:
> See attached
>
> On 2020-02-06 at 8:51 AM, Antonio Scuri 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
See attached
On 2020-02-06 at 8:51 AM, Antonio Scuri 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
escreveu:
No problemo,
The context was: IupSetStrAttribute(txtAsmC
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
escreveu:
> No problemo,
>
> The context was: IupSetStrAttribute(txtAsmCode,'VALUE',pCodeArray) where
> txtAsmCode is a pointer to the
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 wrote:
Hi,
I need more information about the context when the problem occurs.
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
escreveu:
> Hello Antonio,
>
> I just want to remind you that IUP still doesn't
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
Hi Andrew,
On Sun, 1 Dec 2019 17:09:57 -0700
"Andrew Robinson" wrote:
> Antonio,
>
> If you don't feel like having this discussion, let me know and I can
> save it for another time...
Frankly, I don't want to really enter into this discussion.
Just I strongly disagree.
> [...]
> work, otherw
PS -- This is a secret, so don't tell anybody listening: You can leave out
Unicode support in IUP, and still support Unicode. For example, without
Unicode support enabled, most compilers will translate GetCommandLine into
GetCommandLineA (the ANSI version), and with Unicode enabled most compilers
w
This isn't a competition, is it? It takes at most, four lines of code to
convert from one UTF encoding to any other encoding supported by Microsoft.
This is not rocket science.
On 2019-11-30 at 11:21 PM, Pete Lomax via Iup-users
wrote:
On Saturday, 30 November 2019, 18:49:55 GMT, Antonio Scuri
Hi,
Andrew wrote:
>TIP: IUP is just a GUI framework and should not be involved in any UTF
>>standards battles. IUP should just stick to the native encoding of the
>underlying >OS (which is ANSI or UTF-16) and let the programmer be able to
>seamlessly >call native Windows Unicode compliant functi
Antonio,
If you don't feel like having this discussion, let me know and I can save it
for another time...
To avoid confusion, let's get our terminology right: There is no such thing as
a Unicode strings type. Unicode is a standardized enumeration that is not used
anywhere because it is a 21-bit e
Yes, the problem is not the conversion itself.
IUP already use Unicode strings when setting and retrieving native
element strings. The problem is we can NOT change the IUP API without
breaking compatibility with several thousands of lines of code of existing
applications. To add a new API in p
Antonio,
It is a trivial thing to translate between UTF encodings in Windows using the
MultiByteToWideChar() function, but the problem is, there are 711 API
functions in Windows, none of which support UTF-8. They only directly support
ANSI or UTF-16. Read that quote from Microsoft I posted the oth
Might be worth checking out
https://bitbucket.org/knight666/utf8rewind/src/default/ as well...
On Sunday, 1 December 2019, 06:41:57 GMT, Pete Lomax via Iup-users
wrote:
On Saturday, 30 November 2019, 18:49:55 GMT, Antonio Scuri
wrote:
... need conversion functions to/from UTF-8 an
On Saturday, 30 November 2019, 18:49:55 GMT, Antonio Scuri
wrote:
... need conversion functions to/from UTF-8 and the filesystem encoding. Would
be nice to have a solution for that inside IUP, but for now we still don't have
one.
My own routines in Phix are 360 lines, a quick search yielded
Hi Antonio,
Thanks for the professional reply.
"The problem, for now, resumes to convert the string returned by IupFileDlg to
a format that fopen can successfully use"
The problem there is using fopen instead of _wfopen. Those are the only two
basic C-STD choices.
"When ... you need to convert
Hi Andrew,
I still think that we are in the right path. So, the most
promising situation is:
> Action: So then I set UTF8MODE=Yes and UTF8MODE_FILE=Yes and I get the
following:
> Result: All Unicode characters displays properly but I still cannot open
the file with fopen() using the filename
Antonio,
I have a file on a Windows 7 computer (with the default code page for
English), that I rename by cutting and pasting a UTF-8 encoded character from
an Internet page into the filename. What happens then? The browser copies and
converts it to UTF-16 and places it in the clipboard, which I
20 matches
Mail list logo