MessagesForMacintosh/mac_main.h

1 line
8.6 KiB
C
Raw Normal View History

2021-09-11 06:12:19 +00:00
/*------------------------------------------------------------------------------ # # Apple Macintosh Developer Technical Support # # MultiFinder-Aware Simple Sample Application # # Sample # # Sample.h - Rez and C Include Source # # Copyright © 1989 Apple Computer, Inc. # All rights reserved. # # Versions: # 1.00 08/88 # 1.01 11/88 # 1.02 04/89 MPW 3.1 # # Components: # Sample.p April 1, 1989 # Sample.c April 1, 1989 # Sample.a April 1, 1989 # Sample.inc1.a April 1, 1989 # SampleMisc.a April 1, 1989 # Sample.r April 1, 1989 # Sample.h April 1, 1989 # [P]Sample.make April 1, 1989 # [C]Sample.make April 1, 1989 # [A]Sample.make April 1, 1989 # # Sample is an example application that demonstrates how to # initialize the commonly used toolbox managers, operate # successfully under MultiFinder, handle desk accessories, # and create, grow, and zoom windows. # # It does not by any means demonstrate all the techniques # you need for a large application. In particular, Sample # does not cover exception handling, multiple windows/documents, # sophisticated memory management, printing, or undo. All of # these are vital parts of a normal full-sized application. # # This application is an example of the form of a Macintosh # application; it is NOT a template. It is NOT intended to be # used as a foundation for the next world-class, best-selling, # 600K application. A stick figure drawing of the human body may # be a good example of the form for a painting, but that does not # mean it should be used as the basis for the next Mona Lisa. # # We recommend that you review this program or TESample before # beginning a new application. ------------------------------------------------------------------------------*/ /* These #defines correspond to values defined in the Pascal source code. Sample.c and Sample.r include this file. */ /* 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 [is a boy dog] 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 may get lost [will have to be shot]. 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. So, what did we decide on Sample? First, Sample has little risk of running out of memory once it starts. Second, performance isn't much of an issue since it doesn't do much and multiple windows are not