Yes, the problem is not the conversion itself. IUP already use Unicode strings when setting and retrieving native element strings. The problem is we can NOT change the IUP API without breaking compatibility with several thousands of lines of code of existing applications. To add a new API in parallel is something we don't have time to do. So we are still going to use char* in our API for some time. UTF-16 would imply in using wchar* in everything.
What we can do now is to provide some mechanism for the application to be able to use the returned string in IupFileDlg in another control and in fopen. Probably a different attribute will be necessary. Some applications I know are simply using UTF8MODE_FILE=NO, so they can use it in fopen, and before displaying it in another control, converting that string to UTF-8. Best, Scuri Em dom., 1 de dez. de 2019 às 12:43, Andrew Robinson <arobinso...@cox.net> escreveu: > Antonio, > > It is a trivial thing to translate between UTF encodings in Windows using > the MultiByteToWideChar() function, but the problem is, there are 711 API > functions in Windows, none of which support UTF-8. They only directly > support ANSI or UTF-16. Read that quote from Microsoft I posted the other > day, and notice how they said that passing a UTF-8 encoded > string WILL cause some API functions to crash your application. The problem > is, Microsoft has not published a list of all of those unstable API > functions BECAUSE MICROSOFT HAS SAID IT WILL ONLY SUPPORT UTF-16 and ANSI, > and only certain versions of Windows 10 can support UTF-8. > > Code should be not only be readable, maintainable, and modular, it should > also make sense, so if Microsoft choose UTF-16 as their Unicode standard of > choice, why complicate things by choosing a different standard? Adding 711 > UTF-8-->UTF-16 and 711 UTF-16-->UTF-8 translations to those 711 native > Windows API functions would make it unreasonably complicated and clutter > the code. The only time translations should be an "issue" is when you need > to translate text files from and to a different UTF encoding, but like I > said, that is a trivial thing to do. > > TIP: IUP is just a GUI framework and should not be involved in any UTF > standards battles. IUP should just stick to the native encoding of the > underlying OS (which is ANSI or UTF-16) and let the programmer be able to > seamlessly call native Windows Unicode compliant functions without any > additional and unnecessary overhead. > > Regards, > Andrew > > On 2019-11-30 at 11:21 PM, Pete Lomax via Iup-users < > iup-users@lists.sourceforge.net> wrote: > > On Saturday, 30 November 2019, 18:49:55 GMT, Antonio Scuri < > antonio.sc...@gmail.com> wrote: > > ... need conversion functions to/from UTF-8 and the filesystem encoding. > Would be nice to have a solution for that inside IUP, but for now we still > don't have one. > > My own routines in Phix are 360 lines, a quick search yielded this: > https://www.montefusco.com/qs1rboostsrv/ConvertUTF.c which is 540 lines. > Not saying that's the very best, or the right licence, etc, but it should > all be reasonably straightforward?? > > Regards, Pete > > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
