Question

Je ne faisais que bricoler en appelant GetPrivateProfileString et GetPrivateProfileSection dans kernel32 à partir de .NET et suis tombé sur quelque chose d'étrange que je ne comprends pas.

Commençons par cette 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

Si je passe un lpApplicationName (section), aucun lpKeyName ni aucun lpDefault, je devrais obtenir toutes les clés de cette section, ce que je fais: 50% du temps.

Si le fichier ini a le nom lpApplicationName commençant à la première ligne, le tampon ne renvoie rien. Si lpApplicationName stats sur la deuxième ligne du fichier, il renvoie les valeurs attendues.

Au début, j’imaginais qu’il s’agissait d’utiliser la version W et Unicode dans Declare, mais leur modification ne semble pas avoir d’effet.

Qu'est-ce qui me manque?

Était-ce utile?

La solution

Vérifiez si le fichier que vous ouvrez comporte un repère d'ordre byte (a quelques octets marquant le type d’encodage du texte).

Ces appels d'API Windows ne semblent pas s'accrocher aux marques d'ordre d'octets et leur font rater la première section (donc tout fonctionne correctement s'il y a une ligne vide).

Autres conseils

Bon appel. Editer le fichier ini dans VS.NET signifie bien sûr (Duh) ajouter une nomenclature utf-8. Grrr. En l'ouvrant dans le bloc-notes et en exécutant SaveAs ASCII, vous obtenez les résultats escomptés.

Si évident. Si obtus. Une heure de plus dans le marché. : -)

Merci! - = Chris

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top