DocMgrEx.exe is a sample that shows how to support multiple
extensions associated with one document type (or template) in MFC's Doc/View
architecture.
This sample implements the code required to allow
registration, unregistration, file open, and file save operations in an
otherwise regular MFC application. The classes touched include the following:
•
The CWinApp-derived class.
•
The undocumented CDocManager class.
•
A custom CFileDialog-derived class that allows transparent
file operations with the newly defined CDocManagerEx.
NOTE
: To Build this project with VS .NET, change the path
in the #include of AfxImpl.h on line 472 of DocManagerEx.cpp:
Change from
: #include <.."src"afximpl.h>
To
: #include <.."src"mfc"afximpl.h>
For more information about how to download Microsoft Support files,
click the following article number to view the article in the Microsoft
Knowledge Base:
119591
(http://support.microsoft.com/kb/119591/) How to obtain Microsoft support files from online services
Microsoft scanned this file for viruses. Microsoft used the most
current virus-detection software that was available on the date that
the file was posted. The file is stored on security-enhanced servers
that help prevent any unauthorized changes to the file. To change the extensions supported by different document
types, or to add new document types, edit the application's string table. In
the string resource associated with the document type resource ID, the fourth
""n" delimited substring should read as follows:
DocType files (.ex1;.ex2;ex3)
The 5th substring should read as follows:
.ex1;.ex2;.ex3
NOTE: DocType is the external name of the document type; and ex1,
ex2, ex3 are the extensions you want to associate with your document type.
When testing the application, you will notice its behavior is
similar to DevStudio with regard to file open/save operations. For example,
when trying to open a file, the user specifies only a file name (without an
extension), the application will successively append the extensions from the
currently active filter, trying to build the file name of an existing file. If
this yields no result, the application will either tell the user that the file
does not exist (if the OFN_FILEMUSTEXIST flag was specified) or it will create
a new file with no extension. Saving operations are very similar.
To implement correct registration code we needed to override
CDocManager::RegisterShellFileTypes().
Unregistration is a bit more
complicated, because the corresponding functions in CWinApp and CDocManager
were not declared virtual. Therefore, we needed to implement the correct code
in an override of CDocManager::UnregisterShellFileTypes(), and copy and paste
the code from CWinApp::UnregisterShellFileTypes() and
CWinApp::ProcessShellCommand() in our own CWinApp-derived class.
To
implement file operations transparently, we overrode
CDocManager::DoPromptFileName() and CDocManager::OpenDocumentFile(). To
minimize the number of changes, the global function MatchDocType() has been
defined to replace the use of CDocTemplate::MatchDocType() member function. The
new function behaves as expected when multiple extensions are provided for one
document template.