Add line count of FileReadToArray to @extended

[BrewManNH]

The function FileReadToArray doesn't return the count of the lines that were read in, so you have to use UBound to get this information or use _FileReadToArray.

My request is to add the line count by setting the @extended variable to the count of lines returned. This wouldn't be a script breaking change, as the current function doesn't use @extended for anything. It's also not unprecedented, as there are other functions that use @extended for similar features, such as the number of bytes downloaded in the InetRead function, StringRegExpReplace uses it for the number of replacements made, etc.

[mlipok]

I see that your application was created in reference to my:
​http://www.autoitscript.com/trac/autoit/ticket/2645

and indeed such a solution would be much better.

[mlipok]

I see that your request (not application) was created in reference to my:
​​http://www.autoitscript.com/trac/autoit/ticket/2645
and indeed such a solution would be much better.

[anonymous]

Isn't is better to go "_FileReadToArray()" way and have count of the lines returned in zeroth element - $aArray[0]? Why produce essentially different solutions for the same task?

[anonymous]

Wouldn't that prevent you from treating it like any other array of strings?

[BrewManNH]

My suggestion would eliminate the need to use a wrapper function and another #include, just to be able to get the line count. Also, the _FileReadToArray function adds a lot of code that's unrelated to just getting the line count which would add to the size of a script merely to get a line count.

[BrewManNH]

One thing I forgot to add, putting the line count into @extended keeps the array returned as a 0 based array, which _FileReadToArray doesn't, it puts the count in the first element of the array, and the actual file's text starts at element 1. Not a major reason, but some people might appreciate it.

[anonymous]

isn't _FileReadToArray have $iFlag [optional]

0 - disable the return count in the first element - effectively makes the array 0-based (must use UBound() to get the size of the array in this case).
1 - (default), return the array count in the first element.

[BrewManNH]

True forgot about that. But then why do we need that now if we have FileReadToArray, as they would give you the exact same results without the bloat?

[anonymous]

Just by moving something into the environment (the interpreter) doesn't make it less bloated. It is because it isn't part of the environment that the environment isn't bloated.

[BrewManNH]

Have you looked at the latest version of _FileReadToArray? There's so much added code in there that it's definitely bloat when all you want to get is the line count. Adding it to the native version of FileReadToArray would put it in the exe and not in the script and would probably not add much to the overall size. Also, in regards to comment #7, if you disable the return count in 0, then you're just using FileReadToArray, which means your point is moot, because the whole point of this request was to get an easy way to get the line count.

My whole request is to leave the functionality of FileReadToArray alone, by leaving the return as a zero based array, and adding the count in @extended. Without having to resort to using File.Au3, or _FileReadToArray.

[anonymous]

If use FileSetPos and than pass file handle to FileReadToArray the @extended macro as count line would not make sense.

[jchd18]

Why? It would more or less reflect the number of lines read and loaded.

[BrewManNH]

Replying to anonymous:

If use FileSetPos and than pass file handle to FileReadToArray the @extended macro as count line would not make sense.

I'm not looking to get the line count of the file, I'm looking to get the number of lines read into the array. FileSetPos has no effect on what I was asking about because you'd still be reading in a number of lines.

[Jon]

Added by revision [10272] in version: 3.3.13.1