MacApp 3.0 boasts many enhancements over version 2.0. This article surveys these enhancements, and highlights those areas of interest to the developer. This article assumes familiarity with MacApp 2.0.
MacApp 3.0 also supports the new services provided in System 7 by the Gestalt, TextEdit, Resource, and Window Managers. Implementing support for these System 7 managers helped to illuminate many areas where MacApp was deficient. The framework was extended to support the new managers, and it was also improved in many places to address the newly illuminated deficiencies.
MacApp internally represents an AppleEvent as an instance of the TAppleEvent class. The class helps to encapsulate AppleEvent behavior, such as writing to and reading from the AppleEvent message data structure, and retrieving AppleEvent attributes, such as the AppleEvent address and priority.
When MacApp receives an AppleEvent, it creates an instance of TAppleEvent, asks TAppleEvent to internalize the AppleEvent, and then creates a TAppleCommand to serve as a courier of the TAppleEvent. MacApp then propagates the TAppleCommand down the MacApp command handling chain by way of TEvtHandler's DoAppleCommand method.
Although MacApp's support of the Edition Manager required only a few specialized new classes, it illuminated the need for several more-a generalized view adornment for supporting Edition Manager borders, and a mechanism for specifying subranges of data. Also, MacApp now unifies the protocol to support the Edition Manager and the Scrap Manager by way of a flexible stream interface (see below).
A MacApp 3.0 application dispatches Edition Manager AppleEvents, called section events, using its AppleEvent dispatching scheme described above. The TSectionMgr class, a subclass of TEvtHandler, encapsulates handling of the section events. An instance of TSectionMgr is installed at the end of the target chain when an application initializes MacApp's Edition Manager support. TSectionMgr implements a poor-man's AppleEvents Object Model mechanism for targeting the section events to the appropriate section object.
The generalized view adornment in MacApp 3.0 takes the form of the TAdorner class hierarchy. Adorners, a flexible way of modifying how a view renders, were initially motivated by the need to implement borders, which are required to provide user feedback on editions. Adorners are also used for other purposes, such as adorning controls (as determined by the fAdornment field of TControl), drawing a window's resize icon, and for drawing print feedback.
TView owns a list of TAdorner objects over which the view iterates while rendering. Adorners get a crack at imaging either before or after the view's Draw method is called, depending on the adorner's priority (which is assigned when the adorner is initialized). When adorners get called to Draw, they can assume that their view is focused. This means that there is little overhead to support imaging of adorners since no extra focus is required.
Adorners can be used to augment a view's appearance in a number of ways: giving it a drop shadow, framing it, or (in the case of the Edition Manager) imaging a border for publishers and subscribers imaged in the view.
Interestingly, adding adorners addressed a criticism of MacApp 2.0. They eliminated the need for a Focus call in DrawContents after drawing a view's subviews. This was necessary in MacApp 2.0 to call the view's HighlightSelection method. MacApp 3.0 includes a specialized adorner that simply calls its view's HighlightSelection method. Any view that requires its HighlightSelection method to be called (e.g., TGridView) must attach this adorner. Thus, the overhead for focusing after drawing only occurs if the view has any adorners over which it must iterate. For the common case in which a view has no adorners, the view won't need to focus after drawing.
TDesignator provides support for user selection and sub-range specification in the document. Instances of this class designate a "chunk" of the data managed by the document. For example, a subclass of TDesignator, TLinearDesignator, might represent a linear selection in a word processing document, consisting of a beginning and ending offset into the text. Designators help MacApp implement a simple protocol for talking about the user selection. This is necessary to support the Edition Manager in its mapping of a publisher or subscriber to a chunk of the document.
The sleep region that is computed for the call to WaitNextEvent takes into account any view that handles help. This ensures that if the mouse strays outside the view that handles help, MultiFinder will wake up the application so that MacApp can hide that Help Balloon.
The heart of this change notification architecture is the UDependency unit, which implements the TDependencies class (a TSortedDynamicArray), and maintains the dependencies between various objects. For example, you might use this change notification architecture if your application has multiple views on the same data. You would set the views to be dependent on the data objects managed by the application. Whenever any one of the data objects changes, all the views get automatic notification and can render using the new data.
In general, whenever an object changes, a three-phase process occurs:
Using this change notification architecture increased the recalculation speed of the MacApp example spreadsheet, Calc, by several orders of magnitude for a complex spreadsheet.
TViewBehavior, a specialized TBehavior, modifies the behavior of views. A subclass of TViewBehavior might intercept a mouse-down on a view to implement selection and dragging of the view. Attaching this behavior to any view would enable the user to drag any view without the view itself having any knowledge of the dragging behavior.
For example, in MacApp 3.0 TPrintHandler descends from TViewBehavior. This allows printing to be thought of as a specialized behavior added to views to augment view behavior with printing capabilities.
The libraries were reorganized in order to add significant new features to MacApp (such as System 7 support and a flexible change notification mechanism), to incorporate many building blocks (e.g., UTearOffMenu, UFloatWindow, USynchScroller), and to break out classes into their own units (to speed up build times and maintenance).
The result of this new organization is better modularity, allowing classes and methods to be more specialized. It also allows faster access to classes of interest, and reduces build times. For example, a change to TView's DrawContents method simply requires a quick recompile of the UView unit. In MacApp 2.0, a similar change caused a lengthy recompile of the entire UMacApp unit. This change is primarily a benefit to the MacApp team in the development of MacApp, since most developers rarely-if ever-change MacApp source. (Yeah, right.)
TFileBasedDocument interacts with TFile by means of a new class called TFileHandler. TFileHandler manages the process by which a document writes to or reads from a file. TFileHandler decides which of several algorithms to use when saving the file, and defers to the document when it comes to actually reading a data stream from the file. So, subclasses of TFileBasedDocument can map their data to one or more files by means of several TFileHandler instances, each of which interacts with a given file. This new document architecture has allowed each of these classes to be specialized for their particular task, and for TDocument to be as lean as possible.
Any subclass of TCommand that requires mouse tracking should now descend from TTracker. TTracker contains all knowledge of mouse tracking, thus cleaning up TCommand significantly and ensuring that simple subclasses of TCommand don't need to carry around the knowledge of mouse tracking.
This was accomplished by splitting up TView's Focus into two methods, UpdateCoordinates and Focus. The former is called whenever a view's geometry changes, such as when a view is moved, resized, or added as a subview of another view. The latter is called when a view renders. Consequently, the work required to Focus is reduced, as is the need to focus for a variety of common operations.
Floating windows are now fully integrated.
Since allocators now signal failure, it's possible to remove many calls to FailNIL from your code. For example, you no longer have to call FailNIL after creating an instance of a class; the allocator routine that created the instance of that class calls FailNIL for you. This should help to reduce code size.
Since Initialize is now called from the object allocator routine, and all classes implement Initialize, it's now possible to put a newly created object into a known state. This helps significantly in failure handling, so that a newly created object can immediately be freed if a failure occurs. Since the Initialize method isn't allowed to allocate memory, its use is somewhat restricted. However, it is generally useful to modularize initialization of instance variables.
Finally, many classes implement deep-cloning in their Clone method. Deep-cloning is essentially a shallow clone plus special treatment of references to owned objects-in a deep clone, owned objects are also cloned. An object's reference to another object is considered an "owned" reference if the object will be freed in the class' Free method, or if it was created during the class' initialization.
For example, the Rect class contains methods to perform Rect addition, equality tests, and intersections. The String class contains methods to perform string concatenation and character access.
In general, using these classes improves code readability and performance. Where possible, the methods in these classes are declared inline, which eliminates the overhead required for a subroutine call.
We hope that MacApp 3.0 will provide developers with a solid basis for development of ever more powerful and attractive applications.
