Allen - it's not broken so a "fix" would potentially affect all code that properly processes the results and is not a good solution IMO. If anything, the documentation should be updated to clarify that this is not a DELIMITED string but a String LIST of newline-terminated values. The data isn't coming from "nowhere", it's specifically requested because of poor data handling. The documentation, in fact, doesn't reference the returned format at all.

Ruud - the line terminator is Newline (Chr(10)) and not Carriage Return (Chr(13) as you noted.

Rob - Yes, it is returning the intended result.

This is what's happening, and why you aren't processing the data correctly.

Here's a simple example to help it make sense:
If you had a delimited string "A,B,C", you see that it's delimited with commas. There are TWO delimiters that result in 3 fields. The Split() on this string returns a 3-element array. Change this to "A,B,C," and you have 3 delimiters and 4 fields (the last is blank). A split on this returns a 4-element array. This is what you're getting from your code.

The result of ReadProfileString($File, $Section, '') does NOT return a delimited string. It returns a string list - a set of lines terminated with a Newline:
Line1 {NL}
Line2 {NL}
Line3 {NL}

If you look at this as a string, you get this: "Line1 {NL}Line2 {NL}Line3 {NL}" - 3 delimiters so 4 fields. The problem is that this isn't intended to be a delimiter because it isn't just a string, it's a string that contains a set of lines. When you split this using Chr(10) (newline) as a DELIMITER, it includes the last LINE TERMINATOR character and adds an "unseen" empty field. You cannot interchange the use of delimiters and line terminators.

To properly use the output of the ReadProfileString enumeration, you MUST remove the last Line Terminator (because it isn't a delimiter!). THEN and only then can you use the Line Terminator character as a delimiter, because the string now looks like "Line1 {NL}Line2 {NL}Line3" - 2 Delimiters, thus 3 fields.

If you don't eliminate the last LINE TERMINATOR, you wind up with an empty value. Consider what's happening:
 Code:
; Get the keys defined in the section
$aKeys = Split(ReadProfileString($File, $Section, '')
; Enumerate the keys
; just display the result of ReadProfileString for each key - assume there are 3 keys
; but we don't strip the final Line Terminator, so we have 4 elements in the array.
ReadProfileString($File, $Section, $aKey[0]) ?         ; Displays data from "Line 1" key
ReadProfileString($File, $Section, $aKey[1]) ?         ; Displays data from "Line 2" key
ReadProfileString($File, $Section, $aKey[2]) ?         ; Displays data from "Line 3" key
; You have 4 elements, the last is blank
ReadProfileString($File, $Section, $aKey[3]) ?         
; Displays the enumeration of File,Section because $aKey[3] is null! so outputs:
; Line1
; Line2
; Line3
Basically, either trim the last character from the output of the enumeration or use a pre-built function like EnumIni.

The Trim() in my example is not required - it's simply there to create a Boolean result to proceed when any data is returned or skip if a null / empty string was returned. I could have also used an If Not @ERROR instead. The most important thing is first getting the String List, then (if not empty), use Left() and Len() to trim the last line termination character. That logic essentially converts a String List to a Delimited String that can be split into the correct number of fields.

Shane's code is correct because he's removing the final delimiter, albeit through a "golf" mechanism that would not be obvious or intuitive. The left(String, -#) can trim a string by implicitly referencing the length from the end, so his and my examples provide the same result. I would not allow his example in production as it is not a clear/documented method, but something that was "discovered" and leveraged to reduce coding character counts for our Kix-golf games. When his code displays the excess list, it's when he didn't trim the final line terminator.

Finally, Trim() has no bearing whatsoever on processing INI files. You can have blank lines and comments (; or #) to your hearts content in an INI file and there will be zero impact on reading, writing, or enumerating it.


_________________________
Actually I am a Rocket Scientist! \:D