On Aug 7, 2013, at 3:47 AM, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
> Instead of trying to use complex approach to hide the fact you need a global,
> just use one, and don't try to reuse the existing one for things there are
> not designed to do.
>
>
> static id myCallbackHandler;
>
> void someCallBack() {
> [myCallbackHandler handleCallBack];
> }
>
> - (void)foo {
> myCallbackHandler = self;
> callCFunctionWithCallBack(someCallBack);
> myCallbackHandler = nil;
> }
What if instance x does [x foo], and before someCallBack() gets called, some
other instance y does [y foo]? There will be two future calls to
someCallBack(), and [y handleCallBack] will be called both times, which is not
the desired outcome. This is a problem with any approach where the callback
looks in some global place, whether it's a static variable, a key path from the
app delegate, or whatever.
Even if you are sure you won't run into the problem of the global variable
being overwritten, I think routing self through a global like myCallbackHandler
is more complex than:
void someCallBack(void *contextPtr) {
[[(MyClass *)contextPtr autorelease] handleCallBack];
}
- (void)foo {
callCFunctionWithCallBack(someCallBack, (void *)[self retain]);
}
or with ARC:
void someCallBack(void *contextPtr) {
[(__bridge_retained MyClass *)contextPtr handleCallBack];
}
- (void)foo {
callCFunctionWithCallBack(someCallBack, (__bridge_transfer void *)self);
}
This assumes that the API includes a context pointer, but realistically, how
often won't that be the case? (I don't actually know.)
--Andy
>
>
> Le 30 juil. 2013 à 15:44, Maxthon Chan <xcvi...@me.com> a écrit :
>
>> My common way of handling this would be NSNotificationCenter. It is a
>> singleton so I am always sure that it is there, and I can wrap all
>> parameters into the userInfo dictionary.
>>
>> Sent from my iPhone
>>
>>> On 2013年7月30日, at 21:19, KappA <rejek...@gmail.com> wrote:
>>>
>>> I sometimes just access my objc-objects from a C thread-proc via the
>>> AppDelegate (providing there's a trail to the object I need, which there
>>> usually is)... If the callback void pointer parameter isn't being used for
>>> something else, you can simply cast the object in there... or if you need
>>> multiple parameters you can create a struct that stores what you need and
>>> pass that. Not sure if this helps but figured I'd mention it.
>>>
>>> AppDelegate *d = [[UIApplication sharedApplication] delegate];
>>>
>>>
>>>
>>>> On Tue, Jul 30, 2013 at 8:53 AM, lowell <lowe...@me.com> wrote:
>>>>
>>>> The first two parameters to the function have to be an id and a SEL ...
>>>>
>>>> typedef id (*IMP)(id, SEL, ...);
>>>>
>>>> ... (this is where we get self and _cmd, by the way) followed by the rest
>>>> of the method params, if any.
>>>>
>>>>
>>>> lowell
>>>>
>>>>
>>>>> On Jul 30, 2013, at 12:59 AM, Vincent Habchi <vi...@macports.org> wrote:
>>>>>
>>>>> Hi everybody,
>>>>>
>>>>> I have a very simple question: if I embed a C-function (more precisely,
>>>> a callback from an external C-library) in an Obj-C object, can I expect
>>>> this function to behave like a regular method? I.e. can it freely access
>>>> ‘self’ and other attributes?
>>>>>
>>>>> Thanks a lot!
>>>>> Vincent
>>>>>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
