You forgot the attachment
On 2020-05-03 at 7:40 PM, Antonio Scuri <antonio.sc...@gmail.com> wrote: BTW I tested the sample code I sent attached. It worked only in VS 2017, but it worked. So there is hope. But no, it is not a good solution. Best, Scuri Em dom, 3 de mai de 2020 23:35, Antonio Scuri <antonio.sc...@gmail.com> escreveu: 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
