All the programs I sent you are intentionally statically linked with the run time library, except the mingw version. To avoid I have to send you the respective DLL.
No, each Visual Studio now uses a different msvcrt.dll. I uploaded the same samples built to use the run time in a DLL: http://webserver2.tecgraf.puc-rio.br/~scuri/tmp/setlocale_utf8_dll.zip Best, Scuri Em qua., 6 de mai. de 2020 às 10:32, Andrew Robinson <arobinso...@cox.net> escreveu: > 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
