You can use code like that shown in Listing 7-6 to test the TextToBarCoercionHandler handler defined in Listing 7-3.
Listing 7-6 Testing a coercion handler
AEDesc textDesc; |
const char* kText = "1234"; |
OSErr err = AECreateDesc(typeChar, kText, strlen(kText), &textDesc);// 1 |
AEDesc barDesc; |
err = AECoerceDesc(&textDesc, typeBar, &barDesc);// 2 |
if (err == noErr) |
{ |
// Use the descriptor as needed. |
// Dispose of the descriptor when finished with it. |
err = AEDisposeDesc(&barDesc);// 3 |
} |
err = AEDisposeDesc(&textDesc);// 4 |
Here is what the code in this snippet does:
Creates a descriptor containing the text string “1234”.
Calls the Apple Event Manager function AECoerceDesc, passing the text descriptor, the desired type (type bar), and the address of a descriptor in which to store the coerced descriptor.
If the coercion is successful, disposes of the coerced descriptor. Because a coercion returns a new descriptor, your application must dispose of the descriptor when it is finished with it. (This code snippet does not include full error handling.)
Disposes of the text descriptor.
If the coercion fails, you can set a breakpoint in your coercion handler to determine if it is ever called. Possible problems include:
You didn’t install the coercion handler.
The type you passed to AECoerceDesc was different than the type you registered for your coercion handler.
The text descriptor you created has a different descriptor type than you registered for your coercion handler.
You can install a single coercion handler that specifies the constant typeWildCard for both the to and from types. Then any time the Apple Event Manager attempts to dispatch a coercion to the application, it will invoke that handler. This provides a convenient bottleneck for debugging.
Using wildcards can also be convenient as a general way to handle coercions, with one or a small number of handlers converting between supported types and the application’s private data types.
Last updated: 2007-10-31