On Feb 1, 2010, at 00:40:28, Jean-Daniel Dupas wrote:
> Don't bother with custom callback, CFType one works with any objects.
Well, that was the one I tried first, but it failed with the same error.
> 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]
