2009-03-18 13 views
5

Estoy tratando de usar el cuadro de diálogo común de GetOpenFileName() para abrir un cuadro de diálogo y permitir al usuario seleccionar varios archivos.GetOpenFileName() con el indicador OFN_ALLOWMULTISELECT establecido

Tengo el conjunto de banderas OFN_ALLOWMULTISELECT, así como el conjunto OFN_EXPLORER, así que obtengo el cuadro de selección de archivos "nuevo estilo".

Cuando configuro mi estructura OPENFILENAME, tengo ofn.lpstrFile apuntando a un buffer asignado para contener los resultados, y ofn.nMaxFile establecido a su longitud.

El problema que tengo es que si el usuario selecciona tantos nombres de archivo que el búfer se desborda, la llamada a GetOpenFileName devuelve FALSE, y luego CommDlgExtendedError() devuelve FNERR_BUFFERTOOSMALL.

Eso está bien para la detección de errores, y pude aumentar el tamaño del búfer para solucionarlo, pero tarde o temprano el usuario seleccionará suficientes nombres de archivos para desbordar ese búfer.

He visto la nota en MSDN que dice que si el búfer es demasiado pequeño, los primeros dos bytes del búfer lpstrFile contendrán el tamaño requerido, pero el tamaño que devuelve parece demasiado pequeño (quizás esto es correcto cuando OFN_ALLOWMULTISELECT no está configurado). Además, ¡esto requeriría que abriera el diálogo otra vez!

Otro pensamiento que tuve fue crear un procedimiento de enlace de diálogo, y luego detectar el tamaño de los nombres de archivo cuando recibo un mensaje de notificación CDN_SELCHANGE y dinámicamente asignar un búfer del tamaño correcto, pero mientras escribe los datos en el nuevo buffer, parece recordar el valor orignal de ofn.nMaxFile.

¿Alguien sabe la forma correcta de asignar dinámicamente un búfer para contener los resultados de la llamada GetOpenFile sin hacer que el diálogo aparezca dos veces?


Por lo tanto, resulta que el artículo de Martlark está justo en el dinero.

Mis 2 errores fueron:
1) Se me olvidó añadir MAX_PATH en el tamaño de applcate en el gancho, y
2) Esto sólo funciona en la versión Unicode de GetOpenFileName. (Estaba compilando con UNICODE no definido)

+0

He llegado a este mismo problema hace mucho tiempo en el pasado .. ¡Estoy tratando de recordar cómo lo hemos pasado por ti! – RobS

Respuesta

4

Un problema interesante. Supongo que podrías asignar toda la memoria; ¡por si acaso! Sin embargo, este documento sugiere utilizar un proc Gancho:

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

Y todo en una encantadora comprensible OO C no!

+0

Este artículo sugiere una solución que es casi exactamente la misma que el gancho de diálogo que probé. ¡Quizás necesito revisar mi código para asegurarme de que no estoy haciendo nada tonto! - Gracias a un millón por encontrarlo, mi google-fu era débil. –

+0

Tenga cuidado con un error al devolver solo un nombre de archivo al que se insinúa. PD: búsqueda en vivo usada – Martlark

Cuestiones relacionadas