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 in develop; 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. *
