Sorry, clicked a wrong button.
On Aug 7, 2013, at 16:00, Maxthon Chan <xcvi...@me.com> 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 <devli...@shadowlab.org> 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 <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/lowellv%40me.com
>>>>>>
>>>>>> This email sent to lowe...@me.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> 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/rejekted%40gmail.com
>>>>>
>>>>> This email sent to rejek...@gmail.com
>>>> _______________________________________________
>>>>
>>>> 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/xcvista%40me.com
>>>>
>>>> This email sent to xcvi...@me.com
>>>
>>> _______________________________________________
>>>
>>> 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/devlists%40shadowlab.org
>>>
>>> This email sent to devli...@shadowlab.org
>>
>> -- Jean-Daniel
_______________________________________________
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
