I’m trying to use the GetOpenFileName() common dialog box call to pop open a dialog box and allow the user to select multiple files.
I’ve got the OFN_ALLOWMULTISELECT flag set, as well as OFN_EXPLORER set so I get the ‘new style’ file selection box.
When I set up my OPENFILENAME structure, I have ofn.lpstrFile pointing to a buffer allocated to hold the results, and ofn.nMaxFile set to its length.
The problem I’m having is that if the user selects so many filenames that the buffer would overflow, the call to GetOpenFileName returns FALSE, and then CommDlgExtendedError() returns FNERR_BUFFERTOOSMALL.
That’s fine for error detection, and I could up the size of the buffer to fix it, but sooner or later the user will select enough filenames to overflow that buffer.
I’ve seen the note in MSDN that says if the buffer is too small, the first two bytes of the lpstrFile buffer will contain the required size, but the size it’s returning seems to way too small (maybe this is correct when OFN_ALLOWMULTISELECT isn’t set). Plus, this would require me to open the dialog again!
Another thought I had was creating a dialog hook procedure, and then detecting the size of the filenames when I get a CDN_SELCHANGE notify message and dynamically allocate a buffer of the correct size, but while it will write the data in the new buffer, it seems to remember the orignal value of ofn.nMaxFile.
Does anyone know the correct way to dynamically allocate a buffer to hold the results of the GetOpenFile call without making the dialog appear twice?
So, it turns out that Martlark’s article is right on the money.
My 2 mistakes were:
1) I forgot to add MAX_PATH into the size to applcate in the hook, and
2) This only works in the unicode version of GetOpenFileName. (I was compiling with UNICODE not defined)
An interesting problem. I guess you could just allocate all of memory; just in case! But this document suggests using a Hook proc:
http://support.microsoft.com/kb/131462
And all in delightfull understandable non OO C!