Hi,
VS2017 calls a static library while the rest of your programs make a dynamic library call to msvcrt.dll. The code in the static library is much different from the code for setlocale() in the msvcrt.dll. Since I do not have VS2017 on my computer, can you change the default command line parameter/compiler option of VS2017 to switch from making static calls to making calls to a dynamic library? Every version of VS is different from the last one, so I can't tell you how to do that, but I do know that somewhere in VS2017 should be a setting for determining whether an external function should come from a static library or should it be a call to a dynamic library. If you force both programs to do the same thing, then they should act the same way. That in a nutshell is what is going on with your programs. .... but ... The *official* documentation for setlocale() on Microsoft's online help and the help file in their compiler never says they directly support UTF8. What you read online was an unofficial comment and not an official statement. .... but ... You can directly call setlocale() in the msvcrt.dll with the VS2017 program and get consistent results that way, and while that sounds nice, it is only nice so long as MS doesn't suddenly do something in the future to make it so even that doesn't work. Regards, Andrew 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
