Я пытаюсь использовать общий вызов диалогового окна GetOpenFileName (), чтобы открыть диалоговое окно и позволить пользователю выбрать несколько файлов.
У меня установлен флаг OFN_ALLOWMULTISELECT, а также установлен OFN_EXPLORER, поэтому я получаю поле выбора файла "нового стиля".
Когда я настраиваю свою структуру OPENFILENAME, у меня ofn.lpstrFile указывает на буфер, выделенный для хранения результатов, а ofn.nMaxFile устанавливается равной его длине.
Проблема, с которой я столкнулся, заключается в том, что если пользователь выбирает так много имен файлов, что буфер переполняется, вызов GetOpenFileName возвращает FALSE, а затем CommDlgExtendedError () возвращает FNERR_BUFFERTOOSMALL.
Это нормально для обнаружения ошибок, и я мог бы увеличить размер буфера, чтобы исправить это, но рано или поздно пользователь выберет достаточно имен файлов, чтобы переполнить этот буфер.
Я видел заметку в MSDN, в которой говорится, что если буфер слишком мал, первые два байта буфера lpstrFile будут содержать требуемый размер, но размер, который он возвращает, кажется слишком маленьким (возможно, это правильно, когда OFN_ALLOWMULTISELECT не ' т установить). Кроме того, для этого мне потребуется снова открыть диалоговое окно!
Другая мысль, которая у меня возникла, заключалась в создании процедуры подключения диалогового окна, а затем в определении размера имен файлов, когда я получаю сообщение уведомления CDN_SELCHANGE, и динамически выделяю буфер правильного размера, но, хотя он будет записывать данные в новый буфер, кажется чтобы запомнить исходное значение ofn.nMaxFile.
Кто-нибудь знает правильный способ динамического выделения буфера для хранения результатов вызова GetOpenFile, не заставляя диалоговое окно появляться дважды?
Итак, получается, что статья Мартларка не зря.
Мои 2 ошибки:
1) Я забыл добавить MAX_PATH в размер, который нужно применить в хуке, и
2) Это работает только в версии GetOpenFileName в Юникоде. (Я компилировал с UNICODE, не определенным)
