- Which compiler you tested? - What was exactly the code?
char* res = setlocale(LC_ALL, ""); char* res = setlocale(LC_ALL, ".UTF8"); char* res = setlocale(LC_ALL, ".0"); char* res = setlocale(LC_ALL, NULL); char* res = setlocale(LC_ALL, ".NULL"); char* res = setlocale(LC_ALL, "NULL"); Best, Scuri Em seg., 4 de mai. de 2020 às 22:21, Andrew Robinson <arobinso...@cox.net> escreveu: > Preliminary Status: > > The apps that work actually call setlocale() in msvcrt, but with MSVC2017 > and higher, the compiler substitutes calls to LocaleNameToLCID() and > LocaleLCIDToName(). > The Microsoft website was totally useless and incorrect in almost every > regard for how this works, so with a little research I found this: > https://www.science.co.il/language/Locale-codes.php. So instead of using > ".UTF8", I used NULL (the decimal LCID value for UTF8) and it appeared to > work. So I want you to try it too and if it works for you, I will test that > for functionality in my app(s). > > Best Regards, > Andrew > > On 2020-05-04 at 10:23 AM, Andrew Robinson <arobinso...@cox.net> wrote: > > Thanks, got it! Will report back to you with my analysis when I finish my > investigation. > > On 2020-05-04 at 9:23 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote: > > You can download it here: > > http://webserver2.tecgraf.puc-rio.br/~scuri/tmp/setlocale_utf8.zip > > Best, > Scuri > > > Em seg., 4 de mai. de 2020 às 11:57, Antonio Scuri < > antonio.sc...@gmail.com> escreveu: > >> Sure, I can't send it here. But I'll upload it and send you a link >> after lunch. >> >> Best, >> Scuri >> >> Em seg, 4 de mai de 2020 11:54, Andrew Robinson <arobinso...@cox.net> >> escreveu: >> >>> Actually I did read what you wrote, the thing is, it isn't documented to >>> work like that, so I'm curious what Microsoft is up to. I did "forget" that >>> you said it only works with VS2017 but I was distracted by the fact that it >>> was never documented to work like that, so it's a puzzle I want to solve. >>> >>> On 2020-05-03 at 7:35 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote: >>> >>> 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
