Today’s post is about writing code. More specifically, about document and view architectures.
Code isolation, or encapsulation, is where one piece of code knows little or nothing about another. Right now, I am dealing with keeping the Linkage document separate from the Linkage view of that document. The “document” is all of the data for a mechanism that can be saved to a file and then read in later.
An MS Word document contains all sorts of information about fonts, the actual text, colors, etc., but it should probably not know anything about the user zooming in and out. But what if a Word document needs to display something on the screen that does not zoom? I am looking at a Word document in the viewer mode and there are icons to show that there are comments. The comment icon is not a picture that is saved with the word document and neither is the position or size of the icon.
Word Document and Comment Icon
Zooming in and out does not change the size of this comment icon. Is the icon part of the document or part of the view?
The Linkage program has an interesting feature that is similar to the MS Word comment feature. Information can be displayed that is not part of the document. The Linkage program can display dimensions that are generated automatically in the code. They are not saved with the document, or even known to the document handling code.
And now to the crux of the matter; I cannot use the document information alone to export, print, or do anything else visual with the document, because there is not enough information. The information that is missing is the size of the dimension lines that do not change when the view is zoomed in or out. The view knows how big the mechanism is but the document doesn’t. The document code only keep track of the things that the user added to it, not the automatic dimension lines. In fact, even the view code has trouble with the dimensions because they are generated as the view is drawn, not before hand. It is impossible to know how much space is taken by the dimension lines until after that are already visible.
The current way for me to handle this problem is to leave room around the mechanism on the printed page and in exported images, and hope for the best. The screen is only a problem if the user tries to use the “fit” zoom function. Any code that tries to automatically position of the mechanism before drawing it ends up with an incorrect position when using the auto-dimensions.
The problem is that I need to generate the dimension lines before trying to draw them, and then appropriately adjust the mechanism size before using it. If I do that, the document isn’t really an isolated piece of code containing all of the document information. The view contains some of the document information too.