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