I was just tinkering around with calling GetPrivateProfileString and GetPrivateProfileSection in kernel32 from .NET and came across something odd I don't understand.
Let's start with this encantation:
Private Declare Unicode Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringW" ( _
ByVal lpApplicationName As String, _
ByVal lpKeyName As String, _
ByVal lpDefault As String, _
ByVal lpReturnedString() As Char, _
ByVal nSize As Int32, _
ByVal lpFileName As String) As Int32
If I pass an lpApplicationName (section), no lpKeyName and no lpDefault, I should get all of the keys for that section, and indeed I do: 50% of the time.
If the ini file has the lpApplicationName starting on the first line, the buffer returns nothing. If lpApplicationName stats on the second line in the file, it returns the expected values.
At first I though it was a matter of using the W version and Unicode in the Declare, but changing those seems to have no effect.
What am I missing?
Check to see if the file you are opening has a byte order mark (a few bytes marking the type of text encoding).
These Windows API calls don't seem to grok byte order marks and is causes them to miss the first section (hence everything works fine if there is a blank line).
Good call. Editing the ini file in VS.NET is of course (Duh) adding a utf-8 BOM. Grrr. Opening it in notepad and doing a SaveAs ASCII yields the expected results.
So obvious. So obtuse. Another hour down the crapper. :-)
Thanks! -=Chris
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With