Using Windows DLLs and the Windows API in Microsoft Office Development

The Invoice Example with MFC

MFC uses the document-view architecture. The "document" holds the data and the "view" displays it. This is common knowledge. Since we are using POET to hold the data, the document can be modeled as a gateway to the database. The document thus contains all the AllSets and other status parameters (like number of customers, invoices, etc.) that are displayed on the home screen. The status parameters are not stored, since they can be obtained easily from the database. The document also contains the pointer to the currently open database.

Code

The code is simple and follows a pattern. Take a look at a few member functions of the document class that map directly to user interface choices and the code for any of the dialog classes. Most of the code is the standard stuff added by MFC; the interesting parts are the constructors, InitDialog() member, and the functions for handling dialog buttons such as OK. Notice how the dialogs access the members of the document class. All dialogs follow a similar pattern. A few other miscellaneous things have been noted below.

SDI vs. MDI

This is a Single Document Interface (SDI) application. The home screen is the MFC view and displays various status information. All actions on the database are through menu items.

Friends vs. Member Accessors

The dialogs that store the various objects and display data can access the document's members either through accessor functions or through documents giving these dialogs the status of a friend. Both these methods are used for demonstration purposes. However, making the dialogs friends of the document is more elegant and simpler.

Message Handling

When a message is generated, for example when the user makes a choice, MFC gives several objects a chance to handle that message. For example, the same message can be handled by either the application framework, the document, or the view. In this example, the object that will be the most affected by a message handles it.

Conclusion

Since this is an application built for demo purposes, it lacks rigorous error checking and other features that should be a part of any production system. But it is easy to see where such code would fit in, and some of these are indicated by comments.