* Checking string is ASCII

[ColeValleyGirl]

With reference to chcp, I'd be interest to hear how people interpret this (form chcp.

Programs that you start after you assign a new code page use the new code page. However, programs (except Cmd.exe) that you started before assigning the new code page will continue to use the original code page.

What does this mean for programs that you start after you run chcp?

[tatewise]

Yes, I found that a little ambiguous, which is why I ran the tests I mentioned earlier, where I paused a CMD window that had used CHCP 65001 and ran other command windows, none of which used code page 65001.

I suspect it means programs that you start from within this CMD console after it has assigned a new code page.
Whereas programs started earlier in the same CMD console will retain the code page they were launched with.

In other words, it is stating the blindingly obvious.
In a CMD console, any programs that are invoked will inherit the code page in force at the time and that won't change.

[Mark1834]

This thread has wandered around a little, but to report on my discussion with CP - essentially it seems to come down to the new FH7 ini file functions being what they called "thin wrappers" for the underlying MS structure. I assume "thin wrappers" means just passing parameters to and fro with little if any processing. The MS structure does not support "ANSI" encoding, consistent with their move away from this format.

To quote from CP, "fhSetIniFileValue will create a new INI file in ANSI format if you specify a file that doesn't already exist. If you want to use Unicode, you must first create the file yourself as UTF16-LE (with a BOM) before using fhSetIniFileValue". So there is a mismatch between what the CP function does and what the MS control is expecting.

I didn't pick up any intention to fix that mismatch by creating a UTF-16LE file, but they did admit that the FH help description of the functions is misleading and inadequate, and will be updated to explain the workaround in due course.

[ColeValleyGirl]

Mark, not tested but I've seen suggestions that if you create the ini file as an empty UTF16 file just containing a BOM, it will then accept UTF16 characters. See http://archives.miloush.net/michkap/arc ... 54992.html.

This is of course assuming that CP are using the relevant Windows API to implement the function.

Edited to add: Tested and it works.

Code: Select all

fhfu = require ('fhFileUtils')
strFilePath = "D:\\OneDrive\\Desktop\\myini.ini"
bOK = fhSaveTextFile(strFilePath,"", "UTF-16LE")
bOK = fhSetIniFileValue(strFilePath,"Main", "цу", "text", "цонцлусионемяуе цу")
var= fhGetIniFileValue(strFilePath,"Main", "цу", "text", "broken")
print (var)

So I was right in my assumption.

[Mark1834]

Indeed, and possibly also your second suggestion that CP may not have been fully aware of the way the MS structure worked. I can't see them not fixing that not insignificant limitation if they were fully aware of it beforehand...

[SimonOrde]

I don't usually get involved in these discussions, but I wanted to respond to a couple of things Mark said as I thought they might cause confusion. First Mark said: "The MS structure does not support "ANSI" encoding, consistent with their move away from this format". If by the "MS structure" you mean the underlying MS API, this does support ANSI (and UTF16-LE if the INI file is UTF16-LE). The thing it does not support is UTF8. Also Mark said: "there is a mismatch between what the CP function does and what the MS control is expecting". I don't know what this is referring to. There is no mismatch that I am aware of. Finally Mark said "they did admit that the FH help description of the functions is misleading and inadequate." What was actually said was "We will update the Help to make it clearer how to use these functions."