MacApp - Description

Description

This description is based on MacApp 3.0, which had a more advanced underlying model than the earlier 2.0 and differed in many significant ways.

An application built in MacApp followed the command pattern, in which user actions are encapsulated in objects containing event details, and then sent to the proper object to carry them out. In the Mac OS this simple chain of events is actually not all that easy to code "by hand", as the OS only supports extremely basic events like "mouse click" or "keypress". It is the role of MacApp's internal machinery to take these basic events, translate them into semantically higher-level commands, and then route the command to the proper object.

Not only did MacApp relieve the author of having to write this code, which every program requires, but also as a side-effect cleanly separated code into commands and their handlers. In doing so, the resulting program was considered to be, in Apple parlance, factored. This was important under System 7 and later versions of the Mac OS, where commands were expected to flow in not only from the user's actions, but from AppleScript and its underlying Apple Events system as well. Under MacApp, Apple Events were decoded into the same commands as if they had been initiated by direct user actions, meaning that the developer didn't have to write much, if any, code to directly handle Apple Events. This was a major problem for developers using earlier systems, including MacApp 2.0, which had no such separation and often led to Apple Event support being too difficult to bother with.

In keeping with its role as an application framework, MacApp also included a number of pre-rolled objects covering most of the basic Mac GUI—windows, menus, dialogs and similar widgets were all represented within the system. Unfortunately, Apple typically supplied lightweight wrappers over existing internal Mac OS code instead of providing systems that were usable in the "real world". For instance, the TTEView class was offered as the standard text editor, but the underlying TextEdit implementation was severely limited and Apple itself often stated it should not be used at all after the MLTE control was introduced. As a result, developers were often forced to buy add-on objects to address these sorts of needs, or roll their own. The lack of a set of professional quality GUI objects can be considered one of MacApp's biggest problems.

These problem has been addressed with the release of MacApp R16. MacApp R16 uses standard Carbon controls for all MacApp GUI objects. The EditText Carbon control uses the MLTE control for full Unicode Text support. The TTEView class has been superseded by the TMLTEView class which uses the MLTE control for full Unicode Text support.