Joe wrote: > I also discovered from your example that all the different dim as > CF... commands (dim as CFNumberRef, dim as CFNumberRef, dim as > CFStringRef) can be consolidated into one "dim as CFTypeRef" command. > I don't know if there are any advantages or disadvantages to doing > this but it seems easier and less confusing to me. Joe, While it's true that CFNumberRef, CFStringRef, CFDictionaryRef, etc., are ultimately defined as CFTypeRefs, I would stick with the suggested naming convention. You will find that this will make your code more readable and easier to debug. For example, look at one of your Toolbox definitions: toolbox fn CGImageDestinationCreateWithURL( CFURLRef url, ¬ CFStringRef type, ¬ long count,¬ CFDictionaryRef options ) = CGImageDestinationRef This calls for three flavors of Core Foundation Type References (CFTypeRefs): 1. CFURLRef 2. CFStringRef 3. CFDictionaryRef While technically they are all CFTypeRefs-- in all actuality just numbers to be passed to the compiler-- they are each derived in a different manner using different functions. I find this code self documenting: dim as CFURLRef myCFURLRef dim as CFStringRef myCFStringRef dim as CFDictionaryRef myCFDictionaryRef myCFURLRef = fn CreateCFURLFromFSSpec( myFileSpec ) myCFStringRef = fn CFSTR( "myString" ) myCFDictionaryRef = fn CFDictionaryCreate( 0, @key(0), @dictValue (0), 3, keyCallBacks, valueCallBacks ) compared with this: toolbox fn CGImageDestinationCreateWithURL( CFTypeRef ¬ CFTypeRef, ¬ long,¬ CFTypeRef ) = CGImageDestinationRef dim as CFTypeRef aRef, bRef, cRef aRef = fn CreateCFURLFromFSSpec( myFileSpec ) bRef = fn CFSTR( "myString" ) cRef = fn CFDictionaryCreate( 0, @key(0), @dictValue(0), 3, keyCallBacks, valueCallBacks ) Ken