PRB: GetOpenFileName nMaxFile Interpreted Incorrectly

Last reviewed: September 29, 1995
Article ID: Q137194

The information in this article applies to:

Microsoft Win32 Application Programming Interface (API) included with:
```
    - Microsoft Windows 95 version 4.0
```

SYMPTOMS

In a 16-bit Windows-based application, call GetOpenFileName with a string buffer of 10 characters and set nMaxFile to 10. Double-click a file whose full path name is 10 characters long. The file name is returned and the 11th character in the buffer is set to 0. This is a problem because the application has written beyond the specified length of the buffer.

CAUSE

Windows 3.1 had this same problem, so this behavior was maintained in Windows 95 for compatibility reasons.

RESOLUTION

Applications should make sure that they can handle having this API overwrite one more byte than the size that they passed in.

STATUS

This behavior is by design.

Additional reference words: 4.00
KBCategory: kbui kbprb
KBSubcategory: UsrCmnDlg

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 29, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.