Carbon Compatibility Report

Report for: TextDrawIV	Report date: 5/18/2000
File Creator: MNii	Data gathered by analyzer version: 1.3
File Type: APPL	Data gathered on: 5/18/2000

Summary

Test Number Analysis of Imports Supported API 256 Supported with Modifications 2 Supported But Not Recommended 31 Unsupported API 68 Analysis of Access to Low Memory Addresses Analysis of Resources Loaded into System Heap

Supported with Modifications

Common OS Services

Process Manager

Carbon supports most of the Process Manager. The exception is the LaunchDeskAccessory function, which is not supported.

Note that some Process Manager functions access a ProcessInfoRec data structure, which contains fields that are no longer applicable in a preemptively scheduled environment (for example, the processLocation, processFreeMem, and processActiveTime fields). Your application should avoid accessing such fields. Changes to the memory model may also affect certain fields.

GetProcessInformation

Some fields in the ProcessInfoRec structure may no longer be applicable. Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

Human Interface Toolbox

Window Manager

Carbon supports the Window Manager. Be aware, however, that if you use custom window definition procedures (also known as WDEFs), you must compile them as PowerPC-native code. In addition:

• Your application must use the functions defined by the Window Manager whenever it creates and disposes of Window Manager data structures. For example, instead of directly creating and disposing of window records, applications must call such Window Manager functions as GetNewCWindow and DisposeWindow.

• You must revise your application so that it accesses Window Manager data structures only through accessor functions.

• You are encouraged to adopt the standard Mac OS 8 window definition procedures in your application. Applications that use the standard Mac OS 8 window definition procedures inherit the Mac OS 8 human interface appearance. Applications that use custom window definition procedures work correctly, but because custom definition procedures invoke their own drawing routines, Mac OS 8 can’t draw these applications with the current appearance.

NewCWindow

In Carbon, you cannot pass your own storage in to the wStorage parameter. Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

Supported But Not Recommended

Carbon Core

Memory Manager

Carbon supports the majority of the Memory Manager programming interface. Changes primarily affect applications that use zones, system memory, or temporary memory. For example, temporary memory allocations in Mac OS X are allocated in the application’s address space. As a result, calling TempNewHandle is effectively the same as calling NewHandle.

Carbon does not support current functions for accessing the system heap, but on OS X, you can use the POSIX shared memory APIs to achieve this functionality. In addition, the virtual memory system in Mac OS X introduces a number of changes in the addressing model.

By adhering to the following guidelines, you can increase your application’s compliance with Mac OS X memory management:

• Try to use memory only within your own application heap. Review the places where you allocate memory in the system heap.

• Do not pass pointers to data among applications through Apple events, Gestalt routines, or other means. For example, don’t share Toolbox data structures between applications, because in Mac OS X, each application will run in its own protected address space.

• Do not use inline, hard-coded addresses.

• Do not modify the zone header by calling the MoreMasters function. You should instead call the function MoreMasterPointers. Note, however, that master pointer blocks do not need to be preallocated or optimized in the Mac OS X environment, so MoreMasterPointers will only benefit Carbon applications running on Mac OS 8.

• Don’t make assumptions about the layout of memory, such as the relative position of data stored in heaps, stacks, and other memory areas.

• Don’t use the DisposePtr or DisposeHandle functions on pointers or handles allocated by Toolbox managers. For example, don’t call the function DisposeHandle on a control allocated by the NewControl function; use DisposeControl instead.

• Because Mac OS X applications run in a large, protected memory space, memory sizing routines such as MaxMem and FreeMem work differently than before.

MoreMasters

You should instead useMoreMasterPointers.Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

Text and Other International Services

Font Manager

Carbon supports most Font Manager functions. However, you no longer have direct access to Font Manager data structures, and you are not able to access the list of fonts (or the data in those fonts) using the Resource Manager. You should modify your application to use new accessor functions when they are available.

GetFNum

You should instead use FMGetFontFamilyFromName. Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

GetFontName

You should instead use FMGetFontFamilyName. Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TextEdit

Carbon supports nearly all TextEdit functions, but TextEdit functionality has been replaced by Multilingual TextEditor (MLTE). Although there is not necessarily a one-to-one correspondence between APIs in these two technologies, you are encouraged to use MLTE in place of TextEdit.

The Carbon version of TextEdit introduces the following changes:

The low memory accessors for TextEdit structures will be replaced as follows:

TEGet/SetScrapLength replaces LMGet/SetTEScrpLength

TEGet/SetScrapHandle replaces LMGet/SetTEScrpHandle

TEGet/SetDoTextHook replaces LMGet/SetTEDoText

TEGet/SetRecalcHook replaces LMGet/SetTERecal



A new accessor has been added for the FindWord hook: TEGet/SetFindWordHook.

TESetWordBreak will be not available in Carbon, and the wordBreak should not be overriden as a way to customize wordBreak behavior. Instead, override the FindWord hook via the TEGet/SetFindWordHook accessors. Previously, the wordBreak hook was only used on Roman-only systems, a distinction that will not exist in Carbon. TERec's wordBreak field will therefore be completely ignored.

TEActivate

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TECalText

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEClick

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEContinuousStyle

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TECopy

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TECut

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEDeactivate

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEDelete

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEDispose

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEFeatureFlag

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEFromScrap

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEGetHiliteRgn

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEGetOffset

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEGetPoint

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEGetStyleScrapHandle

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEGetText

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEIdle

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEInsert

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEKey

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TESetSelect

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TESetStyle

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TESetText

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEStyleInsert

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEStyleNew

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEStylePaste

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEToScrap

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEUpdate

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

TEUseStyleScrap

Available in Mac OS 8.1 and later when Carbon 1.0.2 or later is present.

Unsupported API

Carbon Core

Low Memory Accessors

Carbon supports many of the accessor functions for low-memory variables. However, you should always avoid using low-memory accessors if there are direct Mac OS Toolbox calls to obtain the same information. For example:

• Use the function TickCount instead of the low-memory accessor function LMGetTicks.

• Use the function FrontWindow instead of the low-memory accessor function LMGetWindowList, when possible.

• Use the function PBGetFCBInfo instead of walking the FCB table with the low-memory accessor function LMGetFCBSPtr.

In general, don’t think of the values returned by low-memory accessor routines as residing in low memory—think of them as information, possibly associated with a specific Toolbox manager, that is returned by the Mac OS. In the future, Apple may supply new functions, distributed among the Mac OS Toolbox managers, for retrieving this information.

Some low-memory accessor functions are obsolete in Mac OS X. The following Resource Manager-related functions are not supported:

• LMGetTopMapHndl and LMSetTopMapHndl

• LMGetSysMapHndl and LMSetSysMapHndl

• LMGetCurMapHndl and LMSetCurMapHndl

LMGetCurDirStore

Not available in Carbon.

LMGetGrayRgn

You should instead use GetGrayRgn. Not available in Carbon.

LMGetSFSaveDisk

Not available in Carbon.

LMGetWindowList

You should instead use GetWindowList. Not available in Carbon.

Memory Manager

Carbon supports the majority of the Memory Manager programming interface. Changes primarily affect applications that use zones, system memory, or temporary memory. For example, temporary memory allocations in Mac OS X are allocated in the application’s address space. As a result, calling TempNewHandle is effectively the same as calling NewHandle.

Carbon does not support current functions for accessing the system heap, but on OS X, you can use the POSIX shared memory APIs to achieve this functionality. In addition, the virtual memory system in Mac OS X introduces a number of changes in the addressing model.

By adhering to the following guidelines, you can increase your application’s compliance with Mac OS X memory management:

• Try to use memory only within your own application heap. Review the places where you allocate memory in the system heap.

• Do not pass pointers to data among applications through Apple events, Gestalt routines, or other means. For example, don’t share Toolbox data structures between applications, because in Mac OS X, each application will run in its own protected address space.

• Do not use inline, hard-coded addresses.

• Do not modify the zone header by calling the MoreMasters function. You should instead call the function MoreMasterPointers. Note, however, that master pointer blocks do not need to be preallocated or optimized in the Mac OS X environment, so MoreMasterPointers will only benefit Carbon applications running on Mac OS 8.

• Don’t make assumptions about the layout of memory, such as the relative position of data stored in heaps, stacks, and other memory areas.

• Don’t use the DisposePtr or DisposeHandle functions on pointers or handles allocated by Toolbox managers. For example, don’t call the function DisposeHandle on a control allocated by the NewControl function; use DisposeControl instead.

• Because Mac OS X applications run in a large, protected memory space, memory sizing routines such as MaxMem and FreeMem work differently than before.

MaxApplZone

This routine is not needed by PowerPC-based applications because they can specify a stack size in the cfrg resource. Not available in Carbon.

Mixed Mode Manager

Mac OS X will not run 68K code. However, Carbon supports universal procedure pointers (UPPs) transparently, so you do not have to change them or remove them from your code. You may want to keep Mixed Mode Manager calls in your application to maintain compatibility with the current version of the Mac OS. Mixed Mode Manager calls from Carbon applications running on Mac OS 8 or 9 function normally.

Typically, applications should use ProcPtrs for their own code and plug-ins and use the new system-supplied UPP creation functions (such as NewModalFilterProc) for Toolbox callback UPPs. You still need to dispose of those UPPs (using the corresponding disposal function), so that any allocated memory can be cleaned up when your application is running on Mac OS 8 or 9.

DisposeRoutineDescriptor

Use a specific UPP disposal routine; e.g., use Dispose ControlDefinitionProc instead of the more general function DisposeRoutineDescriptor. Not available in Carbon.

NewRoutineDescriptor

Applications should use ProcPtrs for their own code and plug-ins, and use the system-supplied UPP creation functions (such as NewModalFilterProc) for Toolbox callback UPPs. You still need to dispose of those UPPs using the appropriate system-supplied disposal function so that any allocated memory can be cleaned up when your application is running on Mac OS 8 or 9. Not available in Carbon.

Patch Manager

Carbon does not support the Patch Manager. Apple is investigating other ways to provide programmatic extensibility.

NGetTrapAddress

Not available in Carbon.

Graphics Services

Printing Manager

Carbon introduces substantial changes to the printing model. The original Printing Manager defined in Printing.h is replaced by a new Carbon Printing Manager defined in PMApplication.h. The Carbon Printing Manager allows applications to print on Mac OS 8 with existing printer drivers and on Mac OS X with new printer drivers.

The following is a summary of the major changes you need to be aware of. More information is available on the Carbon website:

• The Print Record (TPrint) is no longer directly accessible by applications, and has been split into two separate opaque objects: a PrintSettings object and a PageFormat object. Applications will be given references to these two privately-defined data structures. These references are then used to query the Printing Manager for information contained within the objects.

• A consequence of splitting the Print Record and making it private is there are no fixed sizes. Applications will be able to "extend" both the PrintSettings and PageFormat objects, but applications must not assume a specific size when storing and retrieving a PageFormat with documents.

• The Printing Manager will supply functions for flattening and restoring both the PrintSettings and PageFormat object. When storing printing information with documents it will suffice to store just the PageFormat object. If older versions of your application store a print record with a saved document, you may continue to do so to provide backward compatibility.

• Application developers should reduce the use of calls that append items to print dialogs. We expect to provide a new panel-based interface in the near future.

• All print records use the "draft" style, not the "deferred" style, which implies that a print driver must handle the spooling if it wants to provide spooling for the user. Many, if not all, print drivers perform their own spooling and don't require applications to call PrPicFile() to implement spooling. Because it is rarely used, we are eliminating system level spooling code from the Printing Manager.

• The Printing Manager will now enforce an order in which some routines are called. Any routine used out of scope will return an error.

• All Printing Manager routines are only valid within a PMBegin/PMEnd block.

• PrintSettings and PageFormats are automatically disposed of during a PMEnd call.

• The desktop printing functions defined in DesktopPrinting.h are not supported in Carbon.

PrClose

Replace PrClose with PMEnd. Not available in Carbon.

PrCloseDoc

Replace PrCloseDoc with PMEndDocument. Not available in Carbon.

PrClosePage

Replace PrClosePage with PMEndPage. Not available in Carbon.

PrError

Replace PrError with PMError. Not available in Carbon.

PrJobDialog

Replace PrJobDialog with PMPrintDialog. Not available in Carbon.

PrOpen

Replace PrOpen withPMBegin. Not available in Carbon.

PrOpenDoc

Replace PrOpenDoc with PMBeginDocument. Not available in Carbon.

PrOpenPage

Replace PrOpenPage with PMBeginPage. Not available in Carbon.

PrPicFile

This function is obsolete. Printer drivers must perform their own spooling. Not available in Carbon.

PrStlDialog

Replace PrStlDialog with PMPageSetUpDialog. Not available in Carbon.

PrValidate

Replace PrValidate with calls to PMValidatePageFormatand PMValidatePrintSettings. Not available in Carbon.

PrintDefault

Replace PrintDefault with calls to PMDefaultPageFormatand PMDefaultPrintSettings. Not available in Carbon.

QuickDraw Manager

Carbon supports most of the QuickDraw programming interface.

Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports, rather than OpenPort, OpenCPort, ClosePort, and CloseCPort.

Carbon adds functions to get and set port data without accessing port data structures directly. For example, you can use such functions as GetPixBounds, GetPortFillPixPat, SetPortBounds, and SetPortPenSize.

In the past, parts of QuickDraw have been documented in Inside Macintosh as the Color Manager and Cursor Utilities. Note, however, that Inside Macintosh: Imaging with QuickDraw describes animated cursor functions, such as SpinCursor, that are available in the MPW programming environment and possibly in other environments, but not in system software. These animated cursor functions, which are defined in the MPW interface file CursorCtl.h, will not be supported by Carbon.

InitGraf

Not available in Carbon.

Hardware Interfaces

Device Manager

Carbon does not support the Device Manager as an interface for installing or interacting with device drivers.

Carbon supports only the Device Manager APIs that allow applications to read and write to open files.

Other software products that have relied on the Device Manager interface in the past (such as desk accessories)

should be converted into Carbon applications.

Note: The Serial Driver will be supported through a new set of functions similar to PBOpen, PBControl, PBStatus, etc., but specific to serial communication.

OpenDeskAcc

Desk accessories will not be supported in Carbon. A new mechanism will be provided for handling selections from the Apple menu. Not available in Carbon.

Human Interface Toolbox

Dialog Manager

Carbon supports the majority of the Dialog Manager. However, your application must access Dialog Manager data structures only through the supplied accessor functions. Furthermore, your application must use the functions provided for creating and disposing of Dialog Manager data structures.

InitDialogs

InitDialogs is not supported in Carbon. There is no need to initialize the Dialog Manager because the shared library is loaded as needed. Not available in Carbon.

Edition Manager

The Edition Manager and Publish-and-Subscribe functionality are not supported in Carbon.

AssociateSection

Not available in Carbon.

CloseEdition

Not available in Carbon.

CreateEditionContainerFile

Not available in Carbon.

EditionHasFormat

Not available in Carbon.

GetEditionInfo

Not available in Carbon.

GetLastEditionContainerUsed

Not available in Carbon.

GoToPublisherSection

Not available in Carbon.

InitEditionPackVersion

Not available in Carbon.

IsRegisteredSection

Not available in Carbon.

NewPublisherDialog

Not available in Carbon.

NewSection

Not available in Carbon.

NewSubscriberDialog

Not available in Carbon.

OpenEdition

Not available in Carbon.

OpenNewEdition

Not available in Carbon.

ReadEdition

Not available in Carbon.

RegisterSection

Not available in Carbon.

SectionOptionsDialog

Not available in Carbon.

UnRegisterSection

Not available in Carbon.

WriteEdition

Not available in Carbon.

Event Manager

Carbon supports the majority of the Event Manager.

High-level events APIs (as contained in EPPC.h) are not supported. You should use Apple events instead.

Low-level event queue functions, such as GetEvQHdr and PPostEvent, are no longer supported.

Application-defined function-key procedures are not supported in Carbon.

Note that Carbon introduces a new event model to the Mac OS, with a new set of APIs. Developers are strongly encouraged to use the Carbon Event Manager APIs in place of the Event Manager APIs. The Carbon Event Manager offers a simple yet flexible approach to event handling that greatly reduces the amount of code needed to write a basic application. Morevover, the Carbon Event Manager's streamlined event handling enhances system performance on Mac OS X through more efficient allocation of processing time. Applications that use the Carbon Event Manager not only run better on Mac OS X, they help improve overall performance and responsiveness, creating a better experience for our customers.

SystemClick

Desk accessories are not supported in Carbon. Not available in Carbon.

Menu Manager

Carbon supports the Menu Manager, with the following changes:

• Your application must use the functions defined by the Menu Manager whenever it creates and disposes of Menu Manager data structures. Some applications, for example, create menus by using the Resource Manager function GetResource (instead of the Menu Manager function GetMenu) and dispose of them by calling ReleaseResource instead of DisposeMenu. This practice is not supported in Carbon.

• The MenuInfo structure is opaque in Carbon. You must revise your application so that it accesses Menu Manager data structures only through accessor functions.

• There are several Menu Manager functions that deal with manipulating menu color information tables. Apple recommends that you stop using them. The Appearance Manager generally disregards these color tables and instead uses the colors defined for the current appearance.

• You are strongly encouraged to adopt the standard Mac OS 8 menu definition procedures (also known as MDEFs) in your application. Your menus will then inherit the systemwide appearance and, furthermore, take advantage of other Menu Manager enhancements planned for the future. Note, however, that if you must use custom menu definition procedures, you must compile them as PowerPC-native code.

CheckItem

You should instead use CheckMenuItem. Not available in Carbon.

CountMItems

You should instead use CountMenuItems. Not available in Carbon.

DisableItem

Replaced by DisableMenuItem. Not available in Carbon.

EnableItem

Replaced by EnableMenuItem. Not available in Carbon.

InitMenus

InitMenus is not supported in Carbon. There is no need to initialize the Menu Manager because the shared library is loaded as needed. Not available in Carbon.

SystemEdit

Carbon does not support desk accessories. Not available in Carbon.

Scrap Manager

Carbon supports only the LoadScrap and UnloadScrap functions from the original Scrap Manager. However, Carbon supplies new features, including support for "promises," to the Scrap Manager.

GetScrap

You should instead use the functions ScrapHasFlavor, GetScrapFlavorSize, and GetScrapFlavorData. Not available in Carbon.

PutScrap

You should instead use the function PutScrapFlavor. Not available in Carbon.

ZeroScrap

You should instead use the function ClearCurrentScrap. Not available in Carbon.

Standard File Package

Carbon does not support the Standard File Package. You must use Navigation Services instead.

CustomPutFile

Not available in Carbon.

StandardGetFile

Not available in Carbon.

StandardPutFile

Not available in Carbon.

Window Manager

Carbon supports the Window Manager. Be aware, however, that if you use custom window definition procedures (also known as WDEFs), you must compile them as PowerPC-native code. In addition:

• Your application must use the functions defined by the Window Manager whenever it creates and disposes of Window Manager data structures. For example, instead of directly creating and disposing of window records, applications must call such Window Manager functions as GetNewCWindow and DisposeWindow.

• You must revise your application so that it accesses Window Manager data structures only through accessor functions.

• You are encouraged to adopt the standard Mac OS 8 window definition procedures in your application. Applications that use the standard Mac OS 8 window definition procedures inherit the Mac OS 8 human interface appearance. Applications that use custom window definition procedures work correctly, but because custom definition procedures invoke their own drawing routines, Mac OS 8 can’t draw these applications with the current appearance.

CloseWindow

The CloseWindow function is not supported because developers do not allocate their own memory for windows in Carbon. Use the DisposeWindow function to remove a window instead. Not available in Carbon.

InitWindows

InitWindows is not supported in Carbon. There is no need to initialize the Window Manager because the shared library is loaded as needed. Not available in Carbon.

InvalRect

Calls InvalWindowRect, which takes a window pointer as an additional parameter.

Invalidation works on windows, not ports, and because windows are not ports in Carbon, this change is necessary. Not available in Carbon.

InvalRgn

Calls InvalWindowRgn, which takes a window pointer as an additional parameter. Invalidation works on windows, not ports, and because windows are not ports in Carbon, this change is necessary. Not available in Carbon.

Text and Other International Services

Date, Time, and Measurement Utilities

Carbon supports the majority of the Date, Time, and Measurement Utilities. However, obsolete functions that are prefixed with iu or IU (such as IUDateString and IUTimeString) are not supported.

IUDatePString

Use DateString instead. Not available in Carbon.

Font Manager

Carbon supports most Font Manager functions. However, you no longer have direct access to Font Manager data structures, and you are not able to access the list of fonts (or the data in those fonts) using the Resource Manager. You should modify your application to use new accessor functions when they are available.

InitFonts

Not available in Carbon.

Text Services Manager

Carbon supports nearly all Text Services Manager functions. The exceptions are those functions, such as NewServiceWindow and CloseServiceWindow, used to create and manage floating utility windows. If you have a TSM component that uses floating utility windows, you should replace these functions with equivalent Mac OS 8.5 Window Manager functions, which offer more complete support for creating and managing floating windows.

For example, instead of the NewServiceWindow function, you can use the Window Manager function CreateNewWindow, and specify either kFloatingWindowClass or kUtilityWindowClass.

Likewise, use DisposeWindow instead of CloseServiceWindow, GetFrontWindowOfClass instead of GetFrontServiceWindow, and FindWindowOfClass instead of FindServiceWindow.

Finally, the TSMEvent, TSMMenuSelect, and SetTSMCursor functions no longer need to be called, so they are not included in Carbon.

CloseTSMAwareApplication

Not needed in Mac OS X due to the new event model. Not available in Carbon.

InitTSMAwareApplication

Not needed in Mac OS X due to the new event model. Not available in Carbon.

SetTSMCursor

Not needed in Mac OS X due to the new event model. Not available in Carbon.

TSMEvent

Not needed in Mac OS X due to the new event model. Not available in Carbon.

TSMMenuSelect

Not needed in Mac OS X due to the new event model. Not available in Carbon.

Text Utilities

Carbon supports the majority of Text Utilities. However, many obsolete functions (such as those prefixed with iu or IU ) are not supported.

IUCompPString

Use CompareString instead. Not available in Carbon.

TextEdit

Carbon supports nearly all TextEdit functions, but TextEdit functionality has been replaced by Multilingual TextEditor (MLTE). Although there is not necessarily a one-to-one correspondence between APIs in these two technologies, you are encouraged to use MLTE in place of TextEdit.

The Carbon version of TextEdit introduces the following changes:

The low memory accessors for TextEdit structures will be replaced as follows:

TEGet/SetScrapLength replaces LMGet/SetTEScrpLength

TEGet/SetScrapHandle replaces LMGet/SetTEScrpHandle

TEGet/SetDoTextHook replaces LMGet/SetTEDoText

TEGet/SetRecalcHook replaces LMGet/SetTERecal



A new accessor has been added for the FindWord hook: TEGet/SetFindWordHook.

TESetWordBreak will be not available in Carbon, and the wordBreak should not be overriden as a way to customize wordBreak behavior. Instead, override the FindWord hook via the TEGet/SetFindWordHook accessors. Previously, the wordBreak hook was only used on Roman-only systems, a distinction that will not exist in Carbon. TERec's wordBreak field will therefore be completely ignored.

TEInit

There is no need to initialize TextEdit because the shared library is loaded as needed. Not available in Carbon.

Address

Access Type

Located in Function

Comments

No Invalid Access Detected

No resources loaded into system heap.