Retired Document
Important: This sample code may not represent best practices for current development. The project may use deprecated symbols and illustrate technologies and techniques that are no longer recommended.
TECommon.h
/*------------------------------------------------------------------------------------------ |
Program: CPlusTESample 2.0 |
File: TECommon.h |
by Andrew Shebanow |
of Apple Macintosh Developer Technical Support |
Copyright © 1989-1990 Apple Computer, Inc. |
All rights reserved. |
------------------------------------------------------------------------------------------*/ |
#ifndef __TECOMMON__ |
#define __TECOMMON__ |
/* |
These definitions are shared by Rez and C++. We use #define statements |
instead of constants in this file because Rez doesn't support constants, |
and since the 3.0b1 version of Rez doesn't like the C++ comments, we use |
C style comments in this file as well. |
*/ |
/* Determining an application's minimum size to request from MultiFinder depends |
on many things, each of which can be unique to an application's function, |
the anticipated environment, the developer's attitude of what constitutes |
reasonable functionality and performance, etc. Here is a list of some things to |
consider when determining the minimum size (and preferred size) for your |
application. The list is pretty much in order of importance, but by no means |
complete. |
1. What is the minimum size needed to give almost 100 percent assurance |
that the application won't crash because it ran out of memory? This |
includes not only things that you do have direct control over such as |
checking for NIL handles and pointers, but also things that some |
feel are not so much under their control such as QuickDraw and the |
Segment Loader. |
2. What kind of performance can a user expect from the application when |
it is running in the minimum memory configuration? Performance includes |
not only speed in handling data, but also things like how many documents |
can be opened, etc. |
3. What are the typical sizes of scraps that a user might wish to work |
with when lauching or switching to your application? If the amount |
of memory is too small, the scrap will be purged from memory. This |
can be quite frustrating to the user. |
4. The previous items have concentrated on topics that tend to cause an |
increase in the minimum size to request from MultiFinder. On the flip |
side, however, should be the consideration of what environments the |
application may be running in. There may be a high probability that |
many users with relatively small memory configurations will want to |
avail themselves of your application. Or, many users might want to use it |
while several other, possibly related/complementary applications are |
running. If that is the case, it would be helpful to have a fairly |
small minimum size. |
What we did for TESample: |
We determined the smallest heap size that TESample could have and |
still run (24K). For the preferred size we added enough space to permit: |
a. a maximum size TextEdit text handle for each window (4x32000 characters) |
b. a maximum usable TextEdit scrap (32000 characters) |
b. a maximum scrap as a result of Copy (32000 characters) |
d. a little performance cushion (see 2, above) (10K) |
Result: 220K for preferred size |
For the minimum size we took the 24K and then scaled down our requirements |
for a,b, and c above. We thought that providing 76 more would be "lean |
and mean" for a multiwindow program (see 4, above). |
Result: 96K for minimum size |
*/ |
#define kPrefSize 220 |
#define kMinSize 96 |
/* kMinHeap - This is the minimum result from the following |
equation: |
ORD(GetApplLimit) - ORD(ApplicZone) |
for the application to run. It will insure that enough memory will |
be around for reasonable-sized scraps, FKEYs, etc. to exist with the |
application, and still give the application some 'breathing room'. |
To derive this number, we ran under a MultiFinder partition that was |
our requested minimum size, as given in the 'SIZE' resource. */ |
#define kMinHeap (90 * 1024) |
/* kMinSpace - This is the minimum result from PurgeSpace, when called |
at initialization time, for the application to run. This number acts |
as a double-check to insure that there really is enough memory for the |
application to run, including what has been taken up already by |
pre-loaded resources, the scrap, code, and other sundry memory blocks. */ |
#define kMinSpace (64 * 1024) |
/* id of our STR# for error strings */ |
#define kTEDocErrStrings 1024 |
/* The following are indicies into STR# resources. */ |
#define eNoMemory 1 |
#define eNoSpaceCut 2 |
#define eNoCut 3 |
#define eNoCopy 4 |
#define eExceedPaste 5 |
#define eNoSpacePaste 6 |
#define eNoWindow 7 |
#define eExceedChar 8 |
#define eNoPaste 9 |
#define eBadFileType 10 |
#define rMenuBar 1024 /* application's menu bar */ |
#define rAboutAlert 1024 /* about alert */ |
#define rDocWindow 1024 /* application's window */ |
#define rVScroll 1024 /* vertical scrollbar control */ |
#define rHScroll 1025 /* horizontal scrollbar control */ |
/* The following constants are used to identify menus and their items. The menu IDs |
have an "m" prefix and the item numbers within each menu have an "i" prefix. */ |
#define mApple 1024 /* Apple menu */ |
#define iAbout 1 |
#define mFile 1025 /* File menu */ |
#define iNew 1 |
#define iOpen 2 |
#define iClose 4 |
#define iSave 5 |
#define iSaveAs 6 |
#define iRevert 7 |
#define iPageSetup 9 |
#define iPrint 10 |
#define iQuit 12 |
#define mEdit 1026 /* Edit menu */ |
#define iUndo 1 |
#define iCut 3 |
#define iCopy 4 |
#define iPaste 5 |
#define iClear 6 |
#define iSelectAll 8 |
#endif |
Copyright © 2003 Apple Computer, Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2003-01-14