GetOpenFileName（）与OFN_AL​​LOWMULTISELECT标志设置 [英] GetOpenFileName() with OFN_ALLOWMULTISELECT flag set

问题描述

我试图使用GetOpenFilename（）通用对话框调用弹出打开一个对话框，允许用户选择多个文件。

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.

我已经得到了OFN_AL​​LOWMULTISELECT标志设置，以及OFN_EXPLORER设置，所以我得到了新风貌文件选择框。

I've got the OFN_ALLOWMULTISELECT flag set, as well as OFN_EXPLORER set so I get the "new style" file selection box.

当我建立了我的OPENFILENAME结构，我有ofn.lpstrFile指向分配来保存结果的缓冲区，ofn.nMaxFile设置为它的长度。

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.

时遇到的问题是，如果用户选择这么多的文件名，该缓冲器将溢出，调用GetOpenFileName返回FALSE，然后CommDlgExtendedError（）返回FNERR_BUFFERTOOSMALL

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.

我见过的MSDN中的提示说如果缓冲区太小，lpstrFile缓冲区的前两个字节将包含所需的大小，但它返回的大小似乎太小（也许这是正确的，当OFN_AL​​LOWMULTISELECT未设置）。另外，这需要我再次打开对话框！

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!

另外以为我已经是创造一个对话框挂钩过程，然后检测文件名的大小，当我得到一个CDN_SELCHANGE通知消息，并动态分配正确大小的缓冲区，但同时它会在新的缓冲区写入数据，似乎要记住ofn.nMaxFile的一部开拓创新的价值。

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.

有谁知道正确的方式来动态分配一个缓冲区来保存GetOpenFile调用的结果不会使对话框出现两次？

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?

---

所以，事实证明，Martlark的文章是正确的金钱。

So, it turns out that Martlark's article is right on the money.

我的2错误是：结果
1）我忘了MAX_PATH加入到大小的钩子applcate和结果
2）只能在GetOpenFileName的UNI code版本。

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)

推荐答案

这是有趣的问题。我猜你可以只分配所有的记忆;以防万一！但是，该文档建议使用挂钩PROC：

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

和所有delightfull理解非面向对象的C！

And all in delightfull understandable non OO C!

这篇关于GetOpenFileName（）与OFN_AL​​LOWMULTISELECT标志设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！