PRB: Error with GetOpenFileName() and OFN_ALLOWMULTISELECT

• Microsoft Windows Software Development Kit (SDK) 3.1
• Microsoft Win32 Application Programming Interface (API), included with:
  • Microsoft Windows NT 3.5

SYMPTOMS

Assume that the GetOpenFileName() function is called with the Flags parameter set to OFN_ALLOWMULTISELECT (allow for multiple selections in the list box) and OFN_NOVALIDATE (allow for invalid characters in the filename), the lpstrFile parameter points to a 2K buffer, and the corresponding nMaxFile is set appropriately to 2048.

When the GetOpenFileName() function call returns, the complete selection in the list box is not copied to the lpstrFile buffer, but the string in the buffer is truncated.

CAUSE

This is a problem with the GetOpenFileName() function in the current version of COMMDLG.DLL in that the OFN_NOVALIDATE flag cannot be used when multiple selections are allowed.

RESOLUTION

The following are two suggested solutions to this problem:

One solution for this problem is to not use the OFN_NOVALIDATE flag with the OFN_ALLOWMULTISELECT flag. That is, if only the OFN_ALLOWMULTISELECT flag is used, then multiple selections will be copied properly to the text buffer. Note that there is a buffer size limit of 2K bytes for the lpstrFile buffer, and characters are truncated after 2K bytes when the OFN_ALLOWMULTISELECT flag is used.

There is another solution, if both the OFN_ALLOWMULTISELECT and OFN_NOVALIDATE flags must be used simultaneously with GetOpenFileName(). Note that the entire string is always copied into the edit control even though the text gets truncated during the process of copying the text to the lpstrFile buffer. Therefore, one could write a hook procedure and read the entire string from the edit control and use it appropriately instead of using the lpstrFile buffer.

Additional query words:

Keywords : kberrmsg kbCmnDlg kbCmnDlgFileO kbCmnDlgSave kbNTOS350 kbGrpUser
Version : WINDOWS:3.1; winnt:3.5
Platform : WINDOWS winnt
Issue type : kbprb