But you used a compiler to test the functions, right? Which one? This is important because we are testing the run time library that is different depending on the compiler.
Here, calling setlocale(LC_ALL, NULL) did not work in any compiler... Best, Scuri Em ter., 5 de mai. de 2020 às 10:34, Andrew Robinson <arobinso...@cox.net> escreveu: > I didn't test the compilers, I tested the functions. They don't always > work as advertised, and this may be one of those times for some strange > reason that only Microsoft can comprehend. > > I used char* res = setlocale(LC_ALL, NULL); > > On 2020-05-04 at 8:16 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote: > > - 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
