I think you didn't read what I wrote. Please take a look again...

  It is supported starting in Visual Studio 2017.

Best,
Scuri


Em dom, 3 de mai de 2020 22:15, Andrew Robinson <arobinso...@cox.net>
escreveu:

> Now that I've tried it again, I vaguely remember what was wrong with
> setlocale(): ".UTF8" is not supported by Windows. The only languages
> supported by Windows are listed here:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/language-strings?view=vs-2019
> .
>
> Just so other people know, do not confuse locale with code page
> identifiers. The code page identifier can be used by
> MultiByteToWideChar(), WideCharToMultiByte(), and WideCharToMultiByte(),
> but it cannot be used by setlocale().
>
> At least not in Windows.
>
> Regards,
> Andrew
>
> On 2020-05-02 at 2:11 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
>
> > could I recommend that you record this solution in your online help
> file some place where it is easy to see and find, say like Product -->
> International Considerations or something like that? I think it is that
> important.
>
>   Yes. Good point.
>
> > That is not a simple thing to request customers
>
>   Oh, no. That ideia was just for using printf, usually for debugging.
>
> Best,
> Scuri
>
>
> Em sex., 1 de mai. de 2020 às 21:07, Andrew Robinson <arobinso...@cox.net>
> escreveu:
>
>> Ola,
>>
>> Fixing IupConfig() will help a lot. I was doing my own custom ini files
>> but it is far easier and the code is far more readable when using
>> IupConfig().
>>
>> So thanks for that.
>>
>> Microsoft has both a #pragma and a function() for setlocale. I vaguely
>> recall using setlocale() and either I missed something or there was a
>> problem with it because I abandoned that idea. Actually I think I missed
>> something, so I think I need to try this out in my code again. If it works,
>> I think that would be the best all around solution. I think even the
>> clipboard should work with that and I wouldn't even have to translate any
>> documents as Windows would do it for me. So that sounds like a good
>> solution for internationally-compatible apps.
>>
>> I will report back to you how well setlocale() works, and if works
>> well, could I recommend that you record this solution in your online help
>> file some place where it is easy to see and find, say like Product -->
>> International Considerations or something like that? I think it is that
>> important.
>>
>> "If you decide to use this feature, another interesting option is to set
>> the console code page to UTF-8 executing 'chcp 65001' on the command line"
>>
>> That is not a simple thing to request customers to do because Windows
>> doesn't properly support UTF-8 on the console unless you do this:
>> https://blogs.msmvps.com/gdicanio/2017/08/22/printing-utf-8-text-to-the-windows-console/
>>
>> Thanks,
>> Andres
>> ​
>>
>> On 2020-05-01 at 3:11 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
>>
>>   Hi,
>>
>>   I wrote a test that don't even use IUP, just to test fopen with UTF-8.
>> It is attached. I found out that it worked using setlocale only in Visual
>> Studio 2017. It seems to be a new feature. I decide to describe this in the
>> IUP documentation:
>>
>> ---------------------------------------------------------------------------------------------
>>
>>
>> Notice that IUP, CD and IM libraries use the *fopen* based functions to
>> read and write files. In Windows *fopen* expects the filename string in
>> the *ANSI* encoding by default. If your filename, including the path,
>> has characters that can not be converted to ANSI, *fopen* will fail to
>> open the file. In Windows we could use *_wfopen* combined with UTF-8,
>> but this is a Microsoft only function and most of *fopen* usage in these
>> libraries are in portable modules. *This is an IUP limitation in
>> Windows.*
>>
>> The simple workaround is to not use special characters in folders or
>> files name in Windows... Legacy applications will also have the same
>> problem.
>>
>> Another option is to call:
>>
>>  setlocale(LC_ALL, ".UTF8");
>>
>> But it will work for *fopen* only in Visual Studio 2017 or newer
>> Microsoft compilers (*setlocale* will return NULL on other compilers).
>> *fopen* will successfully open the file if filename is an UTF-8 string,
>> even with special characters. So you will be able to set both UTF8MODE and
>> UTF8MODE_FILE to YES.
>>
>> If you decide to use this feature, another interesting option is to set
>> the console code page to UTF-8 executing "chcp 65001" on the command line.
>> This will allow your *printf* output to be properly displayed when using
>> UTF-8 strings. This feature actually works for all Microsoft compilers in
>> Windows, and for MingW, even when *setlocale* returns NULL. Notice that
>> some font packages must be installed for this to fully work for all
>> characters (for instance Chinese, Japanese and Korean, along with some
>> symbols too).
>>
>> ---------------------------------------------------------------------------------------------
>>
>>   Yes, this is all an IUP limitation because its external API do not
>> support Unicode.
>>
>>   I also fixed a bug in IupConfig to handle the case where the system
>> folder has special characters, but they can be converted to ANSI. I was not
>> doing that conversion. Just committed to the SVN.
>>
>> Best,
>> Scuri
>>
>>
>> Em ter., 11 de fev. de 2020 às 22:14, Andrew Robinson <
>> arobinso...@cox.net> escreveu:
>>
>>> Hi Antonio,
>>>
>>> The following code:
>>>
>>>  config = IupConfig();
>>>  IupSetAttribute(config, "APP_NAME", "xyz");
>>>  IupConfigLoad(config);
>>>
>>> only seems to work if the current directory has no atypical
>>> (non-English) characters in it, e.g. -- "E:\My\Files" vs "E:\My…\Files". I
>>> am using the English version of Windows with code page 1252. Iup crashes at
>>> IupConfigLoad within the function IupLineFileClose. The character "…"
>>> is Unicode codepoint 2026 (which translates to UTF-8 as 0xE2 0x80 0xA6).
>>>
>>> Regards,
>>> Andrew
>>>
>>
>>
>
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

Reply via email to