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

Reply via email to