[FAQ] The Mac Programming FAQ 1/4
Chris Thomas
Last update: 5 Apr 95 - don't think twice, it's all faq
Please download a copy of this answer sheet and search it before you
post to the 'net, to help reduce bandwidth.
Please send all correspondence regarding content directly to the current
caretaker and content editor, Chris Thomas, <thund...@delphi.com>.
All submissions sent will be considered to be in the public domain
unless stated otherwise (in which case they will not be included in this
FAQ sheet). This sheet was started and is distributed by Jon W"atte,
whom you may reach as <h...@nada.kth.se>.
This sheet is currently archived on nada.kth.se where you can reach it
using afs as /afs/nada.kth.se/public/ftp/pub/hacks/mac-faq/CSMP_PD_FAQ
or using anonymous FTP as pub/hacks/mac-faq/CSMP_PD_FAQ You can also
find it on rtfm.mit.edu unedr the name macintosh/programming-faq. WWW
version is available as <http://www.nada.kth.se/~d88-jwa/mac-faq.html>.
No FAQ can substitute for real documentation (some of which is
mentioned in this FAQ) If you ask a question in comp.sys.mac.programmer
which has a good answer in one of the important sources, you will probably
not get an answer. (Inside Macintosh, Macintosh Technical Notes being
important sources).
There is NO or VERY LIMITED error checking in the code examples, FOR
BREVITY ONLY. You should make sure you ALWAYS check ALL return codes,
and handle any that you are not prepared to deal with appropriately.
Needless to say, do not use the code as is.
Exciting new stuff: General development tools update. Fat trap
patching.
Topics:
[search for *number* to find a topic quickly]
[topics changed since last FAQ are marked with "+", new topics with ">"]
1. +Development Tools
getting started, tool-specific issues
2. Memory
handles, large arrays, resource handles
3. User Interfacing
menus, windows, events, multitasking
4. Files
Mac fopen, wdrefnums, getting full pathnames
5. Imaging
QuickDraw and the means to avoid it
6. Text
Text editing packages, string conversion
7. Communications and Networking
Serial ports, TCP/IP, sockets
8. Interapplication Communication
AppleEvents, OSA, Scripting, and You
9. +Dynamic Linking & Code Resources
the dynamics of code resources & trap patches
10. Compatibility
gestalt & glue
11. Optional System Software
11.1. QuickTime
codec details and the lack thereof
12. Third-Party Solutions
databases
13. Dessert
yummies the Macintosh Way
14. Contributors
whodunnit
*1* Development and debugging tools for the Macintosh
1.1) Q: What do I need to start writing Macintosh software?
A: A Mac, a lot of time, and a few hundred $. Although you can develop
software on a Classic-type machine, it is not to be attempted by the
weak of heart or stressed of time. If you're doing paid work and/or
work for a company, a Quadra-class machine is a must; remember that your
time costs your employer much more than just your salary. A PowerMac is
highly preferable. 16 MB is a minimum to run at all comfortably, and
Virtual Memory (including RamDoubler, unfortunately) is not suited for
development work. Similarly, if you don't have at least 80 MB free on
your hard disk you need to buy more space. You will also need a CD-ROM
drive.
You need a development system such as CodeWarrior, MPW Pro, Symantec C++
8.0 or Prograph, you need at least some of the New Inside Mac books
(Toolbox Essentials, Files, Memory come to mind) and a good entry-level
third-party book may help.
Once you are up to speed on the general layout of the Mac and its
toolboxes, you should call APDA and order the monthly developer mailing,
which will give you a CD chock full of documentation, utilities and
system software once a month. You will also, obviously, need a CD
player; Apple's own CD300 is a very good buy at the time of this
writing. If you don't have the dough for the monthly mailing
($250/year) you can order a _develop_ subscription; this quarterly
magazine ($30-$50/year) comes with a CD containing most Inside Mac
documentation. Another good product to order is the MacOS SDK, which
for $99 gives you a CD with every API in existence up to and including
the 7.5 Mac Toolbox additions. It's somewhat redundant if you already
have the Developer CD. <ap...@appplelink.apple.com> Apple's Developer
Web has almost all of the contents of the Developer CD online.
<http://www.info.apple.com/dev>
If you don't know how to program, go learn your language of choice
BEFORE attempting a "real" Mac application. Programming is a discipline
often requiring different thought processes than your normal day job. A
beginning book, like Lippman: The C++ Primer, one of the Teach Yourself
C++ books, or the primers available on the CodeWarrior CD, might help.
An indispensable Mac programming tool is the Macintosh Programmer's
Toolbox Reference (MPTA), an up-to-date hypertext reference guide
containing reference material on the New Inside Mac-documented portions
of the Toolbox with lightning-fast look-up and mostly correct usage
hints and code snippets. MPTA can be found on the Developer CD, and is
also offered on a seperate $99 CD. <ap...@applelink.apple.com>
Think Reference version 2.0.1, precursor to MPTA, contains reference
material on many parts of the Mac toolbox with lightning-fast look-up
and mostly correct usage hints and code snippets. While it does not
cover any post-System 7 system additions, nor the modern "universal"
headers format, it does include information on the standard C/C++
libraries. Available wherever fine Symantec products are sold.
1.2) Q: What is the most used Macintosh development system?
A: Out of products on the market, I have no idea; MPW, Think and
products appear to be used. Lately, CodeWarrior has come out of nowhere
and grabbed a large share of the market visibility because they have the
fastest compiler and they generate PowerPC code as well as 68K code.
Among hobbyists, CW seems to be the most popular because of it's low
price, ultra-fast compile times, and support that no other company on
the planet can match. Contact <sa...@metrowerks.com> for info on
CodeWarrior.
In the beginning, the Mac was programmed using Mc68000 assembly or
Pascal; this was reflected in the Old Inside Mac volumes which only gave
Pascal-style and assembly-style interfaces to the Mac toolbox. These
days, Apple tells us to use C or even better C++ for developing new
applications, as that will speed up the transition to PowerPC and also
coming cross-platform efforts. Language Systems have a Pascal for
PowerPC product now, but I don't know about pricing or quality.
CodeWarrior will have an Object Pascal compiler beginning in May '95.
There are also at least two Fortran compilers, at least three SmallTalk
implementations (ObjectWorks, SmallTalk/V and SmallTalkAgents) and
others. There are ways of stripping SmallTalk apps so they're smaller
and faster as standalone apps than in the environment.
Languge Systems has Object Pascal and Fortran for PowerMac. Absoft has
Fortran and C++ for PowerMac. These all require MPW.
There's also a world-class LISP/CLOS implementation from Apple called
Macintosh Common Lisp. Recently, Apple announced that DigiTool has
licensed MCL with the intent (among other things) to provide a PowerMac
version and other updates.
Metrowerks have a Pascal and a C and C++ compiler for both 68k and Power
Macs; the package with the three of them is called "CodeWarrior."
CodeWarrior is conquering the marketplace rapidly, mostly due to the
excellent and generous online support. See comp.sys.mac.programmer.
codewarrior for more information and CodeWarrior-related praise.
<sa...@metrowerks.com>
Zedcor has FutureBasic, which seems to be a very popular... It also
seems to be the only well-supported implementation of BASIC on
Macintosh.
CSI has MacForth, of which I only know the name and someone who says
it's pretty good.
There is another good Common Lisp implementation: Procyon Common Lisp.
I don't know if it is actively supported, but Procyon CL is also
available for DOS, OS/2 and Windows (as Allegro CL/PC) and actively
developed.
A new possible up-and-coming languge is Apple's Dylan, which is
something of a cross between BASIC, Pascal, and C. C-based code can be
used directly from Dylan, but Dylan can't yet be used directly from C.
The Apple Dylan environment is rumored to be as far beyond MPW as MPW is
beyond thick bundles of FORTRAN punch cards.
1.3) Q: Okay, which is the most used Mac programming languge?
A: The existing Macintosh code base is mostly C, with Pascal second, and
C++ catching up quite rapidly in third. Few people are writing
mainstream software in Pascal anymore.
1.4) Q: Where do I find a free/share/copyleftware C compiler for the Mac?
Is there a GCC for the mac? What about the FSF boycott of Apple products?
A: There is no really good solution for a "for-free" C development
system for the Mac. GCC has been ported, but requires the MPW shell and
MPW assembler to run; these have to be bought from APDA. There is a
standalone port of GCC 1.37 on nic.switch.ch:software/mac/src/think_c.
gcc-1.37r14 V1.1 standalone is available for ftp at nic.switch.ch:
software/mac/src/think_c.
A not-entirely-stable port of GCC 2.3.3 to MPW is available for ftp at
atg.apple.com [anyone know the directory?]. A much more solid port of
GCC 1.37 is available for MPW as well.
Stan Shebs <sh...@cygnus.com>, the driving force behind all of the MPW
GCC ports, is working on a new port of GCC 2.5.8.
For those whose main interest is in developing only text-based C/C++
programs, using GCC under MacMiNT might be appropriate. MacMiNT is a
UNIX like operating system ported from the Atari ST which supports many
freely available UNIX utilities like GCC, GDB, make, tcsh, byacc, perl,
and more. MacMiNT stuff can be found at nic.switch.ch in
'software/mac/src/macmint'.
The FSF/LPF boycott of Apple products is over as of January 1995, which
means they will now incorporate changes made for Macintosh into their
main code base, if such changes are easily incorporated, and they
won't be any more antagonistic to Mac programmers than they would be
to any other micro-to-workstation-class programmers.
So what are you waiting for? Go out and port something from GNU! Send in
the changes! We still lack decent free development tools!
1.5) Q: Are there any other free Mac development platforms?
A: The best source for information on free compilers/interpreters, such
as they are, is the Free Compilers FAQ which is written by Brian Connors
<conn...@cleo.bc.edu>. Watch for it in c.s.m.p.info.
1.6) Q: What's the difference between the MPW, Think and CodeWarrior
environments?
A: The main difference is that Think and CodeWarrior are integrated
environments, while MPW provides you with a command-line shell for your
Mac and tools to use in it. MPW also has a slightly higher systems
demand and a much slower linker. CodeWarrior is the fastest overall
enviroment.
The best thing about MPW is that you can write scripts and make files
to do anything you want in the way you want it. Think and CodeWarrior
can be AppleScripted to do builds that require more than one link
operation, but the process is more involved, and neither currently
supports scripting in full.
For the MPW environment, there are three source level debuggers; SADE,
SourceBug and Voodoo Monkey. The latter is an experimental debugger
with support for threads debugging; the middle is bundled with MPW while
SADE has to be bought separately (but is fully scriptable in its own
scripting language). The Metrowerks Debuggers support the MPW .SYM
format.
The Think environments have their own integrated debuggers; the Think
Pascal one has a lot of useful features while the Think C/C++ one is a
little more basic (but is gaining in functionality with each release)
Stepping through source code and looking at variables is generally
faster and easier in Think than the MPW debuggers.
Metrowerks has their own debugger which works like the MPW debuggers; i e
it runs the application standalone and pokes at it from the outside,
while the Think debuggers run the application "wrapped" in a special
environment, making for some subtle interferences with your heap (which
you usually don't notice). The Metrowerks Debugger is Thread
Manager-savvy on the 68k side.
CodeWarrior (Metrowerks C++) is by far the fastest compiler; it can
compile to 68k code on a Power Macintosh for really fast compiles.
Symantec C++ (a k a "Think C++") is the most complete C++, containing an
implementation of templates. CodeWarrior 5 has a limited implementation
of templates. MPW has the most powerful environment, which is
intentionally Unix-like. MPW-hosted versions of both CodeWarrior and
Symantec C++ are available.
Any commercial Mac developer should have CodeWarrior. MPW is an option
which makes sense if you need to develop code for non-CFM OpenTransport or
if you have a ridiculously large number of independent code modules to
compile, or if you're a Unix person. CodeWarrior, in addition to it's own
integrated environment, includes the non-compiler parts of MPW and
MPW-hosted Metrowerks compilers/linkers.
Symantec C++ 8.0 is an option if you're writing for PowerMacintosh.
1.7) Q: What is a good low-level debugger for the Mac?
A: MacsBug is freely available for ftp from <ftp://ftp.apple.com>; log
in as user anonymous and give your FULL e-mail address as password.
MacsBug is your basic monitor-type debugger that takes a few hundred Ks
of memory, and lets you break, step, disassemble, look at the stack etc
of most anything running on your Mac. Since it's free (it's also on the
developer CDs) and provides most of the functionality you need, this is
a popular choice. Macsbug is not PowerMac native, and though
PowerPC-disassembling dcmds are available on the Developer CD, it's
nearly impossible to do any serious PowerMac debugging using it without
going fruit loops in the process.
TMON is another debugger which sports a more mac-like interface; it
provides windows and uses the mouse. It can take as little or much
memory as you want by excluding or including certain areas of
functionality. A nice touch is the 6502 disassembler that you can use
to de-bug the code the IOP processors run on the Mac IIfx and Quadra
900/950.
Jasik Designs has a debugger called The Debugger which can do both low-
and high-level debugging, with or without source and for all types of
code, application, code resources, everything. This is the debugger of
choice for many large developers because of its high power and many
features not found anywhere else. However; newcomers beware! This is
the Lamborghini of debuggers; if you know how to drive it, it is the
fastest way from A to B; if you don't, you'll just end up in the ditch.
As a lady put it: "The man wouldn't know a user interface if it bit him
in the rear." The Debugger is PowerMac native and supports PowerPC
disassembly. It includes an excellent code coverage tool and MacNosy, a
general disassembler. Support is said to be excellent.
<mac...@jasik.com>
1.8) Q: Are there any visual developments environments for the
Mac (comparable to Visual C++)?
A: There is no Visual C++ as such. However, there is a C++ parser/editor
called ObjectMaster which provides good browsing and editing capabilities
if you already have a C++ compiler. A demo is available on the CodeWarrior
CD. Think C++ comes with a browser built-in, and you can edit
dialogs/windows using plain old ResEdit, even for your custom view types.
Symantec C++ 7.0 also bundles a view editor/code generator called Visual
Architect; it is fairly complete and has a good level of integration
into the Think Project Manager.
AppMaker is a GUI builder/code generator. Granted, it's not as nice as
VC++, but it's quite a product in any case.
MarksMan version 3.0 has totally revised TCL templates, and now
generates well-thought-out TCL code. It can also generate ANSI C code
etc.
Also, Neuron Data has their UI tool called Open Interface, which is
better than VC++ and creates code portable across 35 platforms.
Unfortunately it's $2500 per developer per platform. There's also two
other cross-platform products called XVT and Galaxy, the former has
gotten flak on UseNet while the latter reportedly is the premier
cross-platform application builder framework; with everything from
styled text to network support.
There is a fully visual, dynamic, object oriented data-flow-driven
programming language for the Mac called Prograph CPX. It features a
full-featured class library, a powerful, user-extensible GUI Builder, full
access to the entire Mac toolbox, a database engine, high-level interfaces
to SQL, Oracle, etc. But the coolest thing about Prograph is its
interpretative debugger, fully integrated with the visual code editor,
which lets you write your code _while it's running_. Execution
automatically rolls back to where changes you make have relevance. A
PowerMac-native compiler and a Windows version are expected in '95. A
complete demo version is available from <sa...@prograph.com>. Cost is
$695 ($395 for students).
SmalltalkAgents comes with a GUI builder, which lets you draw your
interface, and then outputs the code for you.
If you'd rather do Common Lisp, Macintosh Common Lisp offers a Common
Lisp Object System with support for most Mac interface items; you can
edit code while it is running and build stand-alone applications.
However, all of these tools generate rather larger binaries with larger
system demands than a program written in C. On the other hand; C++
programs require more memory and disk space than programs written in
assembly. It's a trade-off, and I believe this type of tools is the
wave of the near future.
1.9) Q: What class libraries are there for the Mac?
A: Apart from the libraries mentioned above, there are three contenders:
MacApp, TCL, and PowerPlant. "Bedrock" will never be released as a
product, although parts of it surface in TCL 2.0 and other parts will be
the base for the OpenDoc Parts Framework.
MacApp is a heavy-duty class library that has tons of features and a
steep learning curve; it runs under MPW with Pascal or C++, and also
under Think Pascal 4.0 A major application written in MacApp is
PhotoShop.
TCL stands for Think Class Library and comes with Think Pascal, C or
C++. It is a smaller library that still fills most peoples needs; since
Think C implements a subset of C++ (the most important OO concepts such
as virtual functions and inheritance) and the TCL is carefully written
not to take advantage of any C++ features not in Think C, you can use it
with Think C. A major application written in TCL is Lotus 1-2-3. (TCL
1.1.3) Starting with Symantec C++ 7.0, Think Class Library 2.0 using
templates and "real" C++ objects is shipping.
The C++ Standard Template Library (STL) compiles under Symantec C++, but
not CodeWarrior.
PowerPlant is the Metrowerks CodeWarrior offering; it's written by the
guy who designed the Think Class Library, but it has a lot of
differences from the original TCL; for one, it's not a monolithic one
base class framework. On the other hand, it has some catching up to do
before it reaches the level of MacApp. It is gaining quite fast on TCL,
but isn't all there yet. It has the most complete support for
AppleEvents & scripting & drag & drop other modern features.
1.10) Q: How should I debug and test my software?
A: Get ahold of, and install, the extensions DoubleTrouble,
DisposeResource and EvenBetterBusError. They will catch 80% of any
memory related bugs you may have, including many bugs that follow NULL
handles or pointers. (Jasik's Debugger obviates the need for these.)
A low-level debugger is required, and while you install it, install the
"leaks" dcmd which will help you catch memory leaks in your application.
All of these tools are available from <ftp.apple.com>.
1.11) Q: Are there any good Mac programming magazines?
A: One Mac programming magazine I know of is MacTech Magazine (formerly
MacTutor). It covers a variety of Mac programming topics on various
levels. Operating independently from Apple, it has a lot of stuff for
the beginning Mac programmer, as well as occasional nuggets for the more
experienced of us. <custs...@xplain.com>
Another VERY GOOD Magazine is _develop_ which is put out by Apple four
times a year; it comes with a CD containing code for all articles ever
published in _develop_, and a lot of documentation and system software
freebies as well. $30/year in the US. <dev....@applelink.apple.com>
1.12) Q: What about protected memory? I'm sick and tired of re-booting
when my application crashes.
A: Write better software!
Or install The Debugger from Jasik Designs, which can provide your
application with write-protection of critical parts of memory, if you have
a 68030-equipped Mac.
Making the Mac OS memory-protected is tricky, because applications expect
to be able to write to low memory, the system heap, temporary memory,
window lists, and even each other's heaps in some interapplication
communication solutions that date back to before AppleEvents and the PPC
Toolbox.
But fear not, Mac fans! Jonathan Kimmitt has written Patmos, the
"Protected address translation mode operating system". It is an
application that brings the advantages of protected mode programs to
your Quadra class Macintosh by the simple expedient of taking over the
memory management unit of the 68040 in a very simple kernel (<100K in
size), we immediately gain compatibility with the BSD unix program
environment. The advantages of this are as follows:
(a) You can run certain programs (such as /bin/sh) designed for MacBSD
(b) You can compile almost all GNU software including C and C++ without.
modifying the source code in any way
(c) All programs run with a flat 32-meg address space, with no worries
about 32K segments or the other mac paraphernalia.
(d) The majority of program bugs can be caught cleanly without crashing
your mac
(e) All your files are shared between Patmos and MacOS so you can edit
using your favourite mac editor, then immediately compile in Patmos
without having to reboot or copy files around.
The downside is that not all macs use the memory management unit in the
same way, or even have the same kind of MMU, so Patmos may not run on
your particular mac model. However, since the kernel source code is
very small, the task of adapting it to a new environment is very simple,
and once achieved, all application programs running in user mode are
enabled to run without even recompiling.
<ftp://nic.switch.ch in /software/mac/src/patmos>
1.13) Q: I have this library written in (Think) Pascal that I want to use
from Think C/Symantec C, but I get link errors/don't know how to do it.
What should I do?
A: Start by writing a .h file describing the interface. Remember to
declare the Pascal functions "pascal". Build a library with Think Pascal
and convert it with oConv.
Do you get link errors on symbols defined in your Pascal lib? Check the
capitalisation used.
Do you get errors on symbols like LMUL and LDIV? Those functions are
defined in the Think Pascal library Runtime.lib or uRuntime.lib. Include
uRuntime.lib and try again.
Do you get link errors on standard symbols like thePort? This is due to
bad capitalization in Symantec's libs. Run oConv with .v checked. This
will create a TEXT file with a .v extension. Open that with a text
editor and correct the capitalization. Run oConv again, with .v checked
this time too.
Do you still get errors on standard symbols? Are you using Think
C/Symantec C++ version 6 or higher? Then you must open the library (after
converting it) from Think C version 5, and remove the unit named
%_TOOLBOX. (If I'm not mistaken, this is the toolbox init unit, which
you won't need anyway.)
1.14) Q: CodeWarrior vs. Think/Symantec C++: Which is better?
A: There are many factors to consider here.
CodeWarrior is the current de facto standard for C/C++ development.
Symantec recently announced the long-awaited Symantec C++ 8.0 for
PowerMacintosh. It includes all the environment and editor improvements
that we wanted in Symantec C++ 6. It won't run usably in 8 megabytes,
but it does have a wealth of improved editing and project management
capabilities to make up for that.
Someone on c.s.m.p.codewarrior pointed out the difference between
Symantec C++ and Metrowerks C++: Symantec C++ will accept proper C++,
but will generate garbage code. Metrowerks will generate correct code,
but won't accept proper C++.
It's probably best to wait until CW/6 is out, this May, before making a
decision. CW/6 will feature a project manager & editor rewritten from
scratch, along with improvements to the C++ front end and much other
stuff. If you need a compiler now, buy CodeWarrior - if you should ever
need support, you will be most happy that you did.
1.15) Q: Can CodeWarrior read Think libraries?
A: Yes, in a way. Here are the steps required.
1) Secure a copy of Think Pascal and a machine that can run it
2) Import the Think C library into Think Pascal
3) Build a Think Pascal library (in MPW format)
4) Import MPW format library into CodeWarrior
1.16) Q: What are some good books on the subject of learning the Mac
Toolbox?
A: Any of Dan Parks Sydow's several books on the subject. Recommended
also is Dave Mark's Mac Programming C Primer. If you don't know C or
C++, some people recommend Dave Mark's Learn C on the Mac, others don't.
The problem with the book is that it doesn't teach much (or in fact
anything) about the art of programming from a Macintosh perspective.
You receive an introduction to the fundamentals of a particular Mac
programming enviroment and to some basic C or C++. Much better is the
combination of the Symantec C++ manual and _Teach Yourself C++_ by Al
Stevens, an excellent OS-neutral introduction to all of ARM C++, including
templates and exceptions. For ANSI standard C++ (which is not yet
available) you'll have to look elsewhere.
1.17) Q: Source code! I want source code! Where can I find some?
A: Celestin Company, Inc. sells the Apprentice 2 CD-ROM. Apprentice
contains over 600 megabytes of programmer utilities and up-to-date
source code in CodeWarrior, Symantec, and MPW projects for C, C++, and
Pascal. <ftp://ftp.teleport.com/vendors/cci/apprentice/apprentice.hqx>
for an index and info. <cele...@olympus.net>
Also, the alt.sources.mac archive at <ftp://ftpbio.bgsu.edu> contains a
lot of misc. source code and snippets not found elsewhere.
<ftp://nic.switch.ch> is another good source for unique source code.
Info-mac is a good source for source, info-mac/dev/src.
1.18) Q: I'm trying to use a largish array in Think C, but get a "code
overflow" error. This is valid C, why doesn't it work?
A: The ANSI standard does not guarantee that any structure larger than
32767 bytes be correctly handled. Because of historical constraints,
the Mac memory model is built around several small blocks of size 32K or
less; these are used both for code and global/static data. If you want
to use more code or data, you have to turn on "far code" or "far data" -
you still will not get around the restriction of 32K code or data per
compiled file, though.
This is one area where CodeWarrior shines; it works around most such
limitations and it doesn't cost much in performance either!
As opposed to, say, DOS or Windows, however, you can allocate as much
memory as you want (and there is in the machine) and step through it
using ordinary pointers; it's just that global and static data space is
addressed off the A5 register using a 16bit displacement addressing mode
in the 68000 processor.
On the PowerPC, everything is 32bit from the start; that runtime model
is much more like UNIX because it's taken from IBMs AIX. No limitations
there.
*2* Memory
2.1) Q: What is a handle?
A: A handle is a pointer to a pointer to something. However, it is more
than that; creating a handle by taking the address of one of your own
pointers does NOT create a Handle; the Memory Manager will only deal
properly with Handles that are created using NewHandle or something that
calls it (such as NewRgn or GetResource).
2.2) Q: When do I have to lock a Handle?
A: The contents of a Handle may move, and when it does, the pointer your
handle is pointing to is changed to point to the new address so your
handle is always valid. The toolbox may call the memory manager to
allocate more memory pretty much anytime you call it (the toolbox) and
when memory is allocated, your handle may move in memory. Don't
dereference a handle into a pointer (or take the address of a field in a
record a handle is double-pointing to) and then call the toolbox and
expect the pointer to still be valid. The only way to ensure that the
pointer will still be valid is to call HLock on the handle to lock it.
Use HGetState and HSetState to save & restore the "locked" state of a
handle when you lock it.
2.3) Q: How do I dispose of Handles?
A: DisposeHandle (formerly called DisposHandle) once and ONLY once will
do the trick. Trying to dispose of an already disposed Handle is an
error. DoubleTrouble (see above) will catch such bugs when they do
occur.
2.4) Q: What about resources?
A: Calling GetResource returns NULL if the resource is not found or
there is not enough memory, else it returns a handle to the resource.
This handle may be moved or locked like any other handle, but DO NOT
call DisposeHandle to get rid of a resource handle - call
ReleaseResource. DisposeResource (see above) will catch this kind of
bug.
Remember that AddResource makes a resource handle out of an ordinary
handle, and RmveResource or DetachResource makes an ordinary handle out
of a resource handle. You cannot call AddResource with a resource
handle; you have to DetachResource it first.
Resource handles are automagically disposed when the resource file they
belong to is closed.
John Kawakami, onl...@xplain.com
---comp.sys.mac.programmer.info--------------------------------------
comp.sys.mac.programmer.info is primarily for distributing FAQs,
tutorials, news, and similar documents related to programming the
Macintosh. To post, email csmp...@xplain.com
---MacTech Magazine--------------------------------------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:310-575-0925
For more info, ftp://ftp.netcom.com/pub/xp/xplain