The Linkage program is written in C++ using the Microsoft Foundation Classes (MFC). MFC provides C++ classes for things like strings, but also provides a document-view architecture. The idea behind the document-view architecture is that your document is the information that needs to be displayed and the view handles just the display of the document. The view can deal with showing just a page of a multi-page document or an area of a larger spreadsheet. The view will handle zooming, panning, and other view-specific features that have nothing to do with the content of the document.

image

Typical View of a Mechanism

The Linkage program stores the mechanism in a “document” object. The information about the connectors and links is all in that object. If the user uses the view to move a connector, the view tells the document to move the connector. But if the user zooms in or out, pans, or changes things of that sort, the document remains unchanged.

Now the problem; what if the content of the document needs to change for a specific view?

For a Word document, consider a situation where the user wants to get a list of all of the words in the document in alphabetical order with a count next to each one. This is a new view of the document and it seems to make sense for the view object to handle this action. The document need not know that this is even happening. Well, except that the document needs to provide a way for the view to get the words in a list with a count for each one. Otherwise, the view suddenly needs to know a whole lot more about the data it is displaying.

image

Parts View

The linkage program needs a parts view. To do this properly in the view code, I need to not have the view ask the document for its size. The view needs to get the document data and then manipulate it and calculate the size based on how the data is being altered by the view code. This is weird to me because it suddenly puts a bunch of document information into the view code. The size of the mechanism comes from information in the document and its possible that the view can’t know how to calculate this.

I have decided to go ahead and use the view object to handle the parts view. I really should create a C++ hierarchy for this and switch view objects to get the new view. But that would mean dealing with the view change outside of the view object which again violates some code encapsulation rules, at least in my mind. I just don’t want the container of the view to know anything about the alternate view just like it doesn’t know about other view features like fonts sizes.

Some of the measurements in the parts view are not appropriate because the connectors are all moved around to where they don’t actually function. I will also have to add a part that represents the ground since the locations of the ground connectors is now different. Overall, this parts view will be cool but hard to implement.