Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

Archive-name: macintosh/programming-faq

Mac Programming Frequently Asked Questions Answer Sheet
Last update: 10 May 95 - sharp dressed 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, .  
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).  When writing, be sure that you include something 
appropriate in the subject line.  I'm now automatically deleting mail 
with blank or whitespace subjects unread due to the growing nasty 
practice of sending junk email without a subject.  The idea, apparently, 
is to be cute and get you to read the mail without deleting it.  This 
sheet was started and is distributed by Jon Watte, whom you may reach as 
.

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 .

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:  More general dev tools update.  See especially 
question 1.2.  List Manager replacements.  The usual tweaking.

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
   12.1. Databases
       client/server solutions for the masses
   12.2. >Circumventing Toolbox Limitations
       foul baggage begone- List Manager replacements
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 (40 MB 
recommended), 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 CD600 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 subscription.   Apple's 
Developer Web has almost all of the contents of the Developer CD online.  


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.  

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 - 
 for one.

1.2) Q: What is the most used Macintosh development system? 

A: Currently, the three most widely used are CodeWarrior (CW), MPW, and 
Symantec C++, probably in that order, though I don't have any 
statistics.  The latest version of any one of these is adequate for Mac 
development.

CodeWarrior: In early 1994, CodeWarrior came out of nowhere and grabbed 
a large share of the market visibility because they had the fastest 
compiler and they generated PowerPC code as well as 68K code.  Today, 
CodeWarrior has the smoothest development environment and most complete 
C++ implementation, supporting both templates and exceptions.  CW/6 
includes C, C++, and Object Pascal support, and can generate x86 
binaries.  Among hobbyists, CW seems to be the most popular because of 
it's low price, ultra-fast compile time, and support that no other 
company on the planet can match.  See comp.sys.mac.programmer.codewarrior
for more information and CodeWarrior-related praise.  Contact 
.

MPW: The grandaddy of all Mac development environments, descended from 
the original Mac development environment based on a Lisa.  MPW is an 
extremely flexible, powerful, Unix-like command line environment with 
makefile, multiple windows and split-pane support.  Many development 
tools are MPW-based.  MPW Pro comes with C, C++, Pascal, assemblers for 
both 68k and PowerMac, various other useful tools, and the C++-based 
framework MacApp for a reasonable price.  MPW has in the past been 
extremely slow, but shows signs of redemption.  Contact 
.

Symantec C++: This is the eighth-generation descendant of the C
environment favored by Mac developers for over five years.  Symantec C++ 
8.0 is a complete, scriptable, modular development environment including 
C, C++, and soon, a PowerPC assembler.  The C++ implementation supports 
templates.  A development version of a PowerPC C++ compiler supporting 
exceptions and RTTI is available at Symantec's devtools site.  SC++ 8.0 
doesn't at this time support 68k Mac development.  For that purpose, 
you're required to use the old, decrepit TPM development environment, 
which is included.  Contact .

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.

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 C++ second, and 
Pascal finding it's niche in third.  Few people are writing mainstream 
software in Pascal anymore, probably because (a) it's rather hard to 
move to non-Mac platforms (b) Pascal is only rarely being taught past 
the first year in Computer Science.

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 , 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 is the 
Free Compilers FAQ which is written by Brian Connors 
.  Watch for it in c.s.m.p.info.

1.6) Q: What's the difference between the MPW, Think and CodeWarrior 
environments?

A: As of CodeWarrior/6, MPW 3.3, and Symantec C++ 8.0.1 (SC++), 
CodeWarrior will allow faster turnaround times, MPW will provide the 
most flexibility and overall power, and Symantec C++ has the edge with 
regard to helpful project browsing features.

CW C++ supports templates and exceptions, Symantec C++ supports only 
templates, MPW's new compilers are based on Symantec C++.

SC++ 8 doesn't generate 68k code, while pre-CW/6 CodeWarrior requires 
you to use seperate (virtually identical) environments, and builds are 
controlled from a Makefile in MPW, of course.

All three need much hard disk space.  SC++ requires the most RAM.  MPW 
requires the most disk space.

MPW is the slowest, followed distantly by SC++, which is followed 
closely by CodeWarrior.

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.  SC++ and CodeWarrior can 
be AppleScripted to do builds that require more than one link operation, 
but the process is more involved, and CW doesn't currently support 
scripting in full.  SC++ 8 can do builds which require more than one 
link operation.

For the MPW and CodeWarrior environments, there are four source level 
debuggers; Metrowerks, SADE, SourceBug, 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).  Metrowerks Debugger is 
included with CodeWarrior.

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).

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.

BOTTOM LINE:

If you're developing for both Power and regular 68k Macs, you need 
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.  SC++ is an option only for PowerMac development.

1.7) Q: What is a good low-level debugger for the Mac? 

A: MacsBug is freely available for ftp from ; 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.  As of 6.5d10, Macsbug supports PowerPC debugging.

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.  
The Debugger is PowerMac native and supports PowerPC disassembly.  It 
includes an excellent code coverage tool and MacNosy, a general 
disassembler.  Support is direct from the author and generally great.


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 .  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++ 
and CodeWarrior, and versions are available for both.

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 (see above) 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 .

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.  

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.  

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.  To add to the burden, Apple's own software tends to be the 
worst offender in these cases.

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.



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:  See the above discussion on CodeWarrior, Think, and MPW for a full 
understanding of the issues involved.

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 numerous books on the subject.  Recommended 
also is Dave Mark's _Ultimate Mac Programming_ (a Macworld book, for 
some odd reason).  Stay away from Dave Mark's _Learn C on the Mac_ and 
_Learn C++ on the Mac_.

See also Nick DeMello's books review, posted in c.s.m.p.info from time 
to time.

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.  
for an index and info.  

Also, the alt.sources.mac archive at  contains a 
lot of misc. source code and snippets not found elsewhere.

 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's 68k support 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.  The horizon is the limit.

*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 RemoveResource 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.

*3* User / Machine interaction

3.1) Q: How do I read the modifier keys of the keyboard? 

A: Just call EventAvail and check the event.modifiers field. 
Only works when you are in the foreground. You can also use 
GetKeys(), or (as a last resort) check the lo-mem global KeyMap 
directly. 

3.2) Q: How do I move the mouse cursor to a specific position?

A: Wait! Don't do it! There has to be a better way!

If you feel you HAVE to do it (for a game or VERY special simulation 
situation) you can use the Cursor Device Manager documented in the tech 
notes on .  If that manager is not installed, as it's not 
on older Macs, you can use the following code:

You need to have some low-memory globals defined.  they may be defined 
in SysEqu.h.

#define MTemp 0x828
#define RawMouse 0x82c
#define CrsrNewCouple 0x8ce

Note that CrsrNewCouple is actually a combination of two globals, just 
to make our life slightly easier.

The code I use to move the mouse is:

*code*
void

Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

© allanswers.org | Terms of use