By now, many of you have installed one of the beta versions of QuickDraw GX onto your
Macintosh -- and possibly by the time you read this, QuickDraw GX Software
Developer's Kit version 1.0 will be available from APDA. Maybe you've played with
the various sample applications and are now ready to work on your first QuickDraw GX
application. Perhaps you've even read my article indevelop Issue 15, "Getting Started
With QuickDraw GX." In this column, I'll talk about something I referred to briefly in
that article: the two versions of QuickDraw GX's combined graphics and layout
portions, and how to take advantage of the debugging version during the development of
your QuickDraw GX-based application. Along the way I'll update you on a few changes
since I wrote the article.
THE EXTENSIONS OF QUICKDRAW GX
The QuickDraw GX system extension comes in two flavors: a nondebugging and a
debugging version. When you run the QuickDraw GX installer script, the nondebugging
version is installed, including the complete QuickDraw GX system. The nondebugging
version is lean and mean, so it's significantly faster than the debugging version; it
performs quite a bit less error checking than the debugging version.
The debugging version of the extension provides extensive error checking and other
debugging amenities. When developing a QuickDraw GX application, you should use this
version to shake out the bugs. The debugging extension is in the DEBUG Init folder and
is named "GXGraphics (debug)" in version 1.0 (it used to be named
aSecretGraphics.debug); just drag it into your System Folder and reboot. As your
system starts up you'll see the debugging extension's icon displayed before the
QuickDraw GX icon.
An explanation of what's really going on here may help clarify things (and it has
changed): There are actually three extensions within the QuickDraw GX extension --
one for graphics and layout, one for printing, and one for the Finder printing
extension. The QuickDraw GX extension knows, if "GXGraphics (debug)" has already
loaded, to use that extension instead of the nondebugging version of the graphics and
layout extension. (Note that since the debugging extension must load before the
nondebugging version, you should not change the debugging extension's name.)
THE ADVANTAGES OF THE DEBUGGING VERSION DURING DEVELOPMENT
Let's look at some differences between the two extensions, and specifically how to take
advantage of the debugging version during the development of your QuickDraw GX
application.
Notices, warnings, and errors. With the debugging version of the extension, you
can get three types of information about drawing problems: notices, warnings, and
errors. For a complete list of these, look at the graphics errors.h interface file. The
many notices, warnings, and errors defined between #ifdef debugging and #endif
in that file are available only with the debugging version. You'll need to #define
debugging in your application to take advantage of them. (Make sure debugging is
not defined when you build your final version.)
With the nondebugging version, notices aren't available at all, and the list of errors
and warnings you need to respond to in your application consists only of those
relatively few that lie outside #ifdef debugging and #endif in the graphics
errors.h file. Your application must be set up to handle these errors and warnings,
which in general indicate that the QuickDraw GX system could not honor your
application's request. For example:
shape_is_nil size_of_path_exceeds_implementation_limit picture_index_out_of_range
The debugging version checks for errors that you're likely to run into while
developing your application, such as passing a negative pen size to GXSetShapePen or a
curve to GXGetGlyphMetrics. The nondebugging version doesn't check for these types of
errors; it assumes you've already shaken them out of the code.
Validation routines. The GXSetValidation and GXValidateShape routines are
available only in the debugging version. These routines allow your application to tell
whether it's passing valid parameters into a QuickDraw GX function, to validate the
contents of all QuickDraw GX objects (such as a shape, style, and ink) before their
use, and to validate the QuickDraw GX memory your application is using.
Speed optimizations. The nondebugging version has optimizations for speed built in
-- not only fewer error checks but also inline functions. The debugging version
doesn't optimize for speed. This shouldn't have any impact on your application
development except that there's not a one-to-one correspondence between stack crawls
using the debugging and nondebugging versions. A performance analysis of your
QuickDraw GX application should only be donewithout the "GXGraphics (debug)" file in
your Extensions folder.
GraphicsBug. The GraphicsBug debugging tool allows you to explore the contents of
any QuickDraw GX object to make sure it contains the correct information. Another
change from before is that GraphicsBug is available in both the debugging and
nondebugging versions. This ability to spy on an object's contents is important to
your application development because otherwise you could only access information in
objects by making API calls, which would be very tedious during debugging.
There's a slight advantage when using GraphicsBug with the debugging version: heaps
are listed by name rather than by hex address in the Heaps menu.
Memory. The debugging version's memory blocks in the QuickDraw GX heap are a bit
bigger to help detect errors when your application writes over the end of a block: all
the blocks end with the same signature, 'grfx'.
Special MacsBug messages. The debugging version generates MacsBug messages
that are intended solely for the consumption of the Apple engineers in unusual
circumstances. (One of my favorites is "Curious if this ever happens.") If we did our
jobs right, you should never see one of these messages. In case you do, however, we're
really interested in hearing what caused you to receive it; please let us know at
AppleLink APPLE.BUGS.
CLEANING UP
You should design your application to take advantage of the extensive capabilities of the
debugging extension, but turn those capabilities off when you create your final
shipping application, to improve its performance. For example, calling
GXValidateShape with the nondebugging extension installed will only result in a jump
and return (that is, it will be a no-op). This is a wonderful method for testing the
QuickDraw GX dispatcher, but it doesn't help the performance of your application.
In the final compile of your shipping application, you'll most likely want to remove all
calls to validation routines, posting of notices, and extra warnings and errors
available only in the debugging version. One approach would be to have various
compilation flags associated with pairs of #ifdef and #endif to turn these features on
and off.
For more information, see my article in Issue 15 if you haven't already -- or just dig
into the QuickDraw GX documentation. Enjoy your journey into the QuickDraw GX
world!
PETE ("LUKE") ALEXANDER has been providing developer support for QuickDraw
GX ever since it was way up in the air. He's happy it's making its final approach, and
he's hoping it lands smack dab in the middle of your software. As a glider pilot, Luke
knows how important control is -- and with QuickDraw GX, you'll be able to maneuver
your software into spaces you never thought possible. Since QuickDraw GX can help
you do lots of great graphics stunts that you used to have to ask him about, Luke is
about to soar off into the wild blue yonder and do some stunts of his own. Soon he'll be
ready for the preflight check that will launch his sabbatical faster than QuickDraw GX
handles two-byte text. For many weeks he'll be thinking about nothing but white sand
beaches, white puffy clouds, and white-capped mountains. He'll lie on his back and
watch the sway of the trees until they stop reminding him of the swashes of L's. So if
you see him somewhere in Montana, Utah, Nevada, California, or Idaho, be sure to say
hello -- but try not to use any words that have a G and an X in them. *
Thanks to Hugo Ayala, Cary Clark, and Herb Derby for reviewing this column. *