Thought I'd post this just for the future records of people searching. The reason P.Martin couldn't open 612 files is because Wiebe's code sets a buffer size for the absolute file path names. You can try it, find the maximum number of files of same name length you can open without the code returning an empty path array. Then try opening the same number of files with shorter names in the same directory as the files with longer names, you'll find you can open many more. Thats because with Wiebe's code you aren't actually opening files, you are just obtaining the absolute paths for files, then you have to write code to open them. Rick's code is a little misleading in this post; it does open multiple files, but doesn't open a File Dialog box for selecting multiple files, which was the purpose of the post in the first place and I assume what P.Martin was trying to do when he was trying to open 612 files.
So the solution is to either rename files with shorter names, or place them in a directory with a shorter name, OR go into Wiebe's code and increase the file buffer size. I believe you can do this by adding more "123"s to the last element of the string array constant (index 5) at the beginning of the block diagram, corresponding to "nMaxFile". This should increase your file buffer and allow for more file paths to be returned. If the path names overrun the buffer, it wil return an empty array, as P.Martin saw. NOTE: I have not attempted changing this string constant yet, there may be other factors I don't understand with allocating the memory and the windows DLL's. If I get around to it, I'll try it out and post something later.
Michael
