Re: Mixing Obj-C and C "methods"
Re: Mixing Obj-C and C "methods"
- Subject: Re: Mixing Obj-C and C "methods"
- From: Maxthon Chan <email@hidden>
- Date: Wed, 07 Aug 2013 16:00:39 +0800
Sorry, clicked a wrong button.
On Aug 7, 2013, at 16:00, Maxthon Chan <email@hidden> wrote:
> Well here is a reason I think that is valid enough to implement a callback using notifications: that is what Objective-C use for what callbacks used to do, besides target-actions and delegations. In Cocoa, quite a lot of delegated methods are actually mapped to messages.
>
> Here is a snippet, with CGI as the class prefix:
>
> void _CGI_SocketCallback(void *ctxt, int param)
> {
> id objectIdentifier = @((NSUInteger)ctxt); // Treat object pointers as NSUIntegers - that prevents crashes and does not leak memory.
> [[NSNotificationCenter defaultCenter] postNotificationName:CGISocketNotification object:objectIdentifier userData:@{@“param”: @(param)}];
> }
>
> - (void)setUpCallback
> {
> [[NSNotificationCenter defaultCenter] addObserver:self action:@selector(callbackCalled:) name:CGISocketNotification object:@((__bridge NSUInteger)self)];
> }
>
> If needed:
>
> - (void)callbackCalled:(NSNotification *)aNotification
> {
> if ([self.delegate respondsToSelector:@selector(connection:callbackDidCallWithParam:)])
> [self.delegate connection:self callbackDidCallWithParam:[aNotification userInfo][@“param”]];
> }
>
> On Aug 7, 2013, at 15:47, Jean-Daniel Dupas <email@hidden> wrote:
>
>> While all theses methods may look valid, what not simply use a static variable declared in your file ?
>>
>> 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;
>> }
>>
>>
>> Le 30 juil. 2013 à 15:44, Maxthon Chan <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
>>>>>>
>>>>>> 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:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Cocoa-dev mailing list (email@hidden)
>>>>>
>>>>> 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:
>>>>>
>>>>> This email sent to email@hidden
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>> -- Jean-Daniel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden