views:

613

answers:

3

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?

+5  A: 

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).

Rob Walker
Is there a way to tell studio to stop writing BOMS for simple test files?
claco
A: 

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

claco
Yeah -- I've lost that hour myself recently! I don't have a good solution, easiest is checking the file manually before opening it and issuing an error, but doesn't really help the user.
Rob Walker
A: 

This saved me thank you!! I created the text file using visual studio as I could not see an data/ini file to select.

Garry Taylor