Open File Dialog Box -- Pros and Cons

Last reviewed: November 2, 1995
Article ID: Q74612
The information in this article applies to:
  • Microsoft Windows Software Development Kit (SDK) versions 3.1
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT versions 3.5 and 3.51
        - Microsoft Windows 95 version 4.0
    

SUMMARY

Applications can call the common dialog library (COMMDLG.DLL) function GetOpenFileName() to retrieve the name of a file that the user wants to manipulate. Using this DLL provides a common interface for opening files across applications and also eliminates dialog-box message processing within the application's code. However, the application must initialize a structure specific to the dialog box. This article discusses the benefits and costs of using the Open File common dialog, via GetOpenFileName().

MORE INFORMATION

When an application uses the Open File dialog box provided by the common dialog DLL, the primary benefit to that application's users will be a familiar interface. Once they learn how to open a file in one application that uses the DLL, they will know how to open a file in all applications that use it.

Features of the Open File dialog include:

  • A list box of files, filtered by extension, in the current directory
  • A list box of directories from root of current drive to current directory, plus subdirectories
  • A combo box of file types to list in filename list box
  • A combo box of drives available, distinguished by drive type
  • An optional "Read Only" check box
  • An optional "Help" button
  • An optional application hook function to modify standard behavior
  • An optional dialog template to add private application features

For the application's programming staff, the benefits of using the Open File common dialog will include:
  • No dialog-box message processing necessary to implement the Open File dialog box
  • Drive and directory listings are constructed by the DLL, not by the application
  • A full pathname for the file to be opened is passed back to the application, and this name can be passed directly to the OpenFile function
  • Offsets into the full pathname are also returned, giving the application access to the filename (sans pathname) and the file extension without the need for parsing
  • The application can pass in its own dialog box template, in which case the DLL will use that template instead of the standard template
  • The application can provide a dialog hook function to extend the interface of the DLL or to change how events are handled
  • The application can choose to have a single filename or multiple filenames returned from the dialog box

The cost for the programming staff could be in adapting previously written application code to handle the common dialog interface. While making this change is straightforward, it does require coding time. If the application only needs a filename with no path, the Open File common dialog is probably not appropriate.

For more information on using the Open File common dialog, query on GetOpenFileName().


Additional reference words: 3.10 3.50 3.51 4.00 95
KBCategory: kbui
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: November 2, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.