File Viewer Structure and Implementation

A file viewer is an OLE component object in an in-process server DLL where the object implements the IPersistFile and IFileViewer interfaces. The in-process server exports the DllGetClassObject and DllCanUnloadNow functions, implements a class factory object with the IClassFactory interface, and implements the file viewer object with the interfaces required. The following illustration shows the structure of a file viewer.

There are a number of reasons why a file viewer is best implemented in a DLL with the given interfaces. In general, a DLL is faster to load and usually comes in a small package. In the future, these same DLLs will provide other nonuser interface features, such as content indexing, and a component object DLL will be the most efficient and fastest way to access those features. In some cases, a file viewer object may need to display pop-up windows and process messages through its own message loop as in Windows 95. The DLL structure still allows this when used in conjunction with a stub process like Quick View, which gives the file viewer DLL the right to execute a message loop.

The IPersistFile interface in the file viewer object is intended to be a general mechanism through which the object is given a path for a file. From then on, the component that loaded the object can ask it to do any number of things with the file. Through Quick View, the Windows 95 shell asks the object to show the file by using the IFileViewer::ShowInitialize and IFileViewer::Show member functions or asks the object to print the file to a specific printer by using the IFileViewer::PrintTo member function. In the future, the shell may ask the object to perform content indexing, which would happen through an interface other than IFileViewer. For this reason, the file loading member functions of IPersistFile are separate from the operations that perform on the file, which is why IFileViewer was not just extended with its own Load member function. This latter option is a little more efficient (because it avoids IPersistFile entrypoint functions that are not implemented), but the design given here is easier to extend.