Don't bother with custom callback, CFType one works with any objects.
Le 1 févr. 2010 à 09:32, Rick Mann a écrit :
> I tried doing this:
>
> const void*
> retainCallback(CFAllocatorRef inAlloc, const void* inValue)
> {
> NSObject* val = (NSObject*) inValue;
> [val retain];
> return val;
> }
> void
> releaseCallback(CFAllocatorRef inAlloc, const void* inValue)
> {
> NSObject* val = (NSObject*) inValue;
> [val release];
> }
>
> CFDictionaryKeyCallBacks
> sKeyCallbacks =
> {
> 0,
> retainCallback,
> releaseCallback,
> NULL,
> NULL,
> NULL
> };
>
> CFDictionaryValueCallBacks
> sValCallbacks =
> {
> 0,
> retainCallback,
> releaseCallback,
> NULL,
> NULL,
> NULL
> };
>
> - (BOOL)
> application: (UIApplication*) inApp
> didFinishLaunchingWithOptions: (NSDictionary*) inOptions
> {
> mFactoriesByLayer = (NSMutableDictionary*)
> CFDictionaryCreateMutable(kCFAllocatorDefault,
> 3,
> &sKeyCallbacks,
> &sValCallbacks);
>
> .
> .
> .
>
> [mFactoriesByLayer setObject: factory forKey: factory.layer];
>
> }
>
> But the setObject fails.
>
> However, since you say I can store arbitrary keys on the object, that's the
> better way to go. I didn't realize one could do this.
>
> Thanks!
>
> On Feb 1, 2010, at 00:26:53, Roland King wrote:
>
>> Tollfree Bridging is a little more complicated than that. They may end up
>> being the same object under the covers, but even if they are, the
>> NSDictionary version doesn't come with the range of options that the
>> CFDictionary does. Just make a CFDictionary(), the default for it is to
>> retain keys (and values) so it's actually really, really easy; I use them
>> all over the place for stuff like this.
>>
>> If a have a non-NSDictionary compatible CFDictionary() like that by the way
>> I use toll free bridging for reading values from it, but I don't use it for
>> setting them, it doesn't seem to work.
>>
>> By the way, CALayer is a KVC compliant class so you can in fact just store a
>> reference to an arbitrary object in it with
>>
>> [ layer setValue:value forKey:@"KeyForObjectAssociatedWithLayer" ];
>>
>> and save yourself a whole world of pain.
>>
>> Richard Penwell wrote:
>>> I thought NSDictionary and CFDictionary were the same data object, that
>>> whole toll free bridging...
>>> An ugly hack would be to cast the pointer to a numeric type, and encode
>>> that in a NSNumber... but I would feel very very ashamed of doing so.
>>> On Feb 1, 2010, at 3:10 AM, Roland King wrote:
>>>> Because NSDictionary requires keys to be copyable because it copies them
>>>> (it's in the documentation). Use a CFDictionary() instead, you can set it
>>>> up to retain the keys and do what you want.
>>>>
>>>> Rick Mann wrote:
>>>>
>>>>> I'd like to use a CALayer object as a key in a dictionary. The reason is
>>>>> that when my app detects a hit in a layer, I need to quickly determine
>>>>> which object I've associated with it. Since I can't store a reference to
>>>>> an arbitrary object in the CALayer, a dictionary seems to be the most
>>>>> expedient way to do that.
>>>>> Unfortunately, I can't seem to add my layer as the key (it fails with
>>>>> "-[CALayer copyWithZone:]: unrecognized selector sent to instance
>>>>> 0x50132a0"). It's really pretty handy to be able to use any object as a
>>>>> key, why is this not the case in Obj-C?
>>>>> TIA,
>>>>> Rick
>>>>> _______________________________________________
>>>>> Cocoa-dev mailing list ([email protected])
>>>>> Please do not post admin requests or moderator comments to the list.
>>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>>>>> This email sent to [email protected]
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list ([email protected])
>>>>
>>>> Please do not post admin requests or moderator comments to the list.
>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/cocoa-dev/almightylinuxgod%40mac.com
>>>>
>>>> This email sent to [email protected]
>
> _______________________________________________
>
> Cocoa-dev mailing list ([email protected])
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
>
> This email sent to [email protected]
>
-- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
