GetPrivateProfileString Oddity - PullRequest
       13

GetPrivateProfileString Oddity

5 голосов
/ 24 сентября 2008

Я просто возился с вызовами GetPrivateProfileString и GetPrivateProfileSection в kernel32 из .NET и наткнулся на что-то странное, чего я не понимаю.

Давайте начнем с этого заклинания:

    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

Если я передаю lpApplicationName (section), не lpKeyName и lpDefault, я должен получить все ключи для этого раздела, и я действительно получаю: 50% времени.

Если в ini-файле lpApplicationName начинается с первой строки, буфер ничего не возвращает. Если lpApplicationName stats во второй строке файла, он возвращает ожидаемые значения.

Сначала я думал, что речь идет об использовании W-версии и Unicode в объявлении, но изменение их, похоже, не дает никакого эффекта.

Чего мне не хватает?

Ответы [ 2 ]

9 голосов
/ 24 сентября 2008

Проверьте, имеет ли открываемый файл метку порядка байтов (несколько байтов, обозначающих тип кодировки текста).

Похоже, что эти вызовы Windows API не вызывают пометки порядка байтов и заставляют их пропустить первый раздел (следовательно, все работает нормально, если есть пустая строка).

1 голос
/ 24 сентября 2008

Хороший звонок. Редактирование INI-файла в VS.NET, конечно (Duh), добавляет UTF-8 BOM. Хмм. Открыв его в блокноте и выполнив SaveAs ASCII, вы получите ожидаемые результаты.

Так очевидно. Так тупо. Еще час спустился вниз. : -)

Спасибо! - = Chris

...