Editing MacApp (section)

==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.''

The Mac OS itself has a very simple event handing system. The event structure passed from the operating system to the application has only an event type like "keypress" or "mouseclick", and details of its location and the modifier keys being held down. It is up to the application to decode this simple information into the action the user carried out, for instance, clicking on a menu command. Decoding this could be difficult, running through lists of on-screen objects and checking if the event took place within their bounds.

MacApp provided a solution to this problem using 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. The logic of mapping the event to the "proper object" was handled entirely within the framework and its runtime, greatly decreasing the complexity of this task. It is the role of MacApp's internal machinery to take the basic OS 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 this design cleanly separated code into ''commands'', user-facing actions, and their ''handlers'', the internal code that did the work. For instance, one might have commands for "Turn Green" and "Turn Red", both of which are handled by a single function, <code>ChangeColor()</code>. A program that cleanly separated commands and handlers was known, in Apple parlance, ''factored''.

Factoring of a program was particularly important in later versions of the Mac OS, starting with [[System 7]]. System 7 introduced the [[Apple Events]] system, which expanded the original Mac OS's event system with a much richer one that could be sent between applications, not just from the OS to a particular application. This was combined with the [[AppleScript]] system which allowed these Events to be generated from scripting code. In MacApp 3.0, 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 left out.

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 <code>TTEView</code> class was offered as the standard text editor widget, but the underlying TextEdit implementation was severely limited and Apple itself often stated it should not be used for professional applications. 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 (API)|Carbon]] controls for all MacApp GUI objects. For instance, Carbon introduced the [[Multilingual Text Engine]] (MLTE) for full [[Unicode]] text and long-document support. In R16, the original <code>TTEView</code> class has been superseded by the <code>TMLTEView</code>, which uses the MLTE control.