2009-03-18 3 views
5

J'essaie d'utiliser l'appel de la boîte de dialogue commune GetOpenFileName() pour ouvrir une boîte de dialogue et permettre à l'utilisateur de sélectionner plusieurs fichiers.GetOpenFileName() avec l'indicateur OFN_ALLOWMULTISELECT défini

J'ai le drapeau OFN_ALLOWMULTISELECT ensemble, ainsi que OFN_EXPLORER ensemble ainsi j'obtiens le "nouveau style" boîte de sélection de dossier.

Lorsque j'ai configuré ma structure OPENFILENAME, ofn.lpstrFile pointe sur un buffer alloué pour contenir les résultats et ofn.nMaxFile sur sa longueur. Le problème que j'ai est que si l'utilisateur sélectionne tant de noms de fichiers que le tampon dépasserait, l'appel à GetOpenFileName retourne FALSE, et CommDlgExtendedError() retourne FNERR_BUFFERTOOSMALL. C'est très bien pour la détection d'erreur, et je pourrais augmenter la taille du tampon pour le réparer, mais tôt ou tard, l'utilisateur sélectionnera suffisamment de noms de fichiers pour déborder ce tampon.

J'ai vu la note dans MSDN qui dit que si le tampon est trop petit, les deux premiers octets du tampon lpstrFile contiendront la taille requise, mais la taille qu'il retourne semble trop petite (peut-être c'est correct lorsque OFN_ALLOWMULTISELECT n'est pas défini). De plus, cela nécessiterait que j'ouvre à nouveau le dialogue! Une autre pensée que j'ai eue était de créer une procédure de hook de dialogue, puis de détecter la taille des noms de fichiers quand j'obtiens un message de notification CDN_SELCHANGE et allouer dynamiquement un buffer de taille correcte, mais pendant qu'il écrira les données dans le nouveau tampon, il semble se souvenir de la valeur orignal de ofn.nMaxFile.

Est-ce que quelqu'un sait la bonne façon d'allouer dynamiquement un tampon pour contenir les résultats de l'appel GetOpenFile sans faire apparaître la boîte de dialogue deux fois?


Donc, il s'avère que l'article de Martlark est juste sur l'argent.

Mes 2 erreurs ont été:
1) J'oublié d'ajouter MAX_PATH dans la taille à applcate dans le crochet et
2) Cela ne fonctionne que dans la version unicode de GetOpenFileName. (Je compilais avec UNICODE pas défini)

+0

J'ai déjà rencontré ce même problème il y a bien longtemps dans le passé ... J'essaie de me rappeler comment nous l'avons dépassé pour vous! – RobS

Répondre

4

Un problème intéressant. Je suppose que vous pourriez juste allouer toute la mémoire; Au cas où! Mais ce document suggère d'utiliser un proc Hook:

http://support.microsoft.com/kb/131462

Et dans delightfull compréhensible non OO C!

+0

Cet article suggère une solution qui est presque exactement la même que le hook de dialogue que j'ai essayé. J'ai besoin de regarder par-dessus mon code pour m'assurer que je ne fais rien de stupide! - Merci mille fois pour le trouver, mon google-fu était faible. –

+0

Attention à un bug lors du retour d'un seul nom de fichier qui est fait allusion à. PS: utilisé Live Search – Martlark

Questions connexes