Hi Marco,

Thanks a lot for this research! We can now fix FAA accordingly.

>>>Hi,
>>>
>>>One FoxInCloud user reports running VFP under code page 65001, which is equivalent to UTF-8
>>>
>>>His Windows copy is in English.
>>>
>>>Does anyone know how this is possible?
>>>
>>>TIA
>>
>>Well this seems to be good news ( though seems we're just gettig aware of it! ):
>>
>>"In April 2018 with insider build 17035 (nominal build 17134) for Windows 10, a "Beta: Use Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling "narrow" functions, including fopen and SetWindowTextA, with UTF-8 strings. In May 2019 Microsoft added the ability for a program to set the code page to UTF-8 itself, and started recommending that all software do this and use UTF-8 exclusively.[1]"
>>
>>Attached an image of the option in Region Settings.. will check it and see how it goes for VFP.
>>
>>
>>
>>https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows#cite_note-Microsoft-UTF-8-1
>>https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
>>https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do
>
>So far, after testing the new setting, seems VFP is unable to set the codepage;
>( setting codepage=auto / codepage=65001 in config is ignored , falls back to 1252 )
>cpcurrent(1) , cpcurrent(2) returns 65001, cpcurrent() returns 1252.
>A text file created in UTF-8 shows ok in editor, but editing fails when typing latin characters like áéñ , showing � .
>
>Perhaps VFP has baked the set of codepages it can work with and adding the manifest ( "Fusion manifest for an unpackaged Win32 app") won't work either.. maybe Chen can give a light or take advantage of this new feature.