Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
- Subject: Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
- From: Jonathan Mitchell <email@hidden>
- Date: Tue, 08 Mar 2016 21:16:55 +0000
Alex
> On 8 Mar 2016, at 20:59, Alex Zavatone <email@hidden> wrote:
>
> I'm browsing the Dubrovnik classes now to see the it handles returning the data now and am thinking of using another Obj-C object to register itself to have the data I care about sent to it.
KVO is very particular about the occurrence and sequencing of the willChangeValueForKey: and didChangeValueForKey: methods. Get it right and joy Reigns. Get it wrong and well…
It can tolerate some missing calls on the end component of a key path but a failure higher up a key path chain is usually fatal. Of course there are potential memory issues too. The objects in an observed key path need to stick around while the observation is live.
In Dubrovnik I translate the managed INotifyPropertyChanging and INotifyPropertyChanged interface events into their KVO equivalents. I incorporated a simple tracking mechanism that fired out warnings if an anomaly in the KVO xxxChangeValueForKey: sequencing occurred.
It took a bit of time to get the kinks out of it all but in the end I have a system that works reliably and enables me to bind many hundreds of NSControl instances to properties of .Net managed classes.
So the KVO route may not be dead, just wounded. In my case to get things sweet I had to disable automatic KVO notifications. For regular Cocoa classes auto KVO is the way to go but if you need more precise control maybe not.
J
>
> Yeah, it's getting complex, that's for sure.
>
>
>
> On Mar 4, 2016, at 7:06 PM, John McCall wrote:
>
>>
>>> On Mar 4, 2016, at 4:03 PM, Greg Parker <email@hidden> wrote:
>>>
>>>
>>>> On Mar 4, 2016, at 2:24 PM, Jonathan Mitchell <email@hidden> wrote:
>>>>
>>>> Hi Alex
>>>>
>>>> Not sure if this will help at all as I am not 100% sure what you are doing.
>>>> In my case, using Mono, I needed to track events being raised in the Mono C runtime back into Obj-C space.
>>>> You need some method of defining a call back function in the target C Api - without that thinks would look rather bleak.
>>>>
>>>> Basically the C Mono runtime is configured to a call static C function in an Obj C .m file in response to a C# managed event firing.
>>>> The static then calls a static method on an Obj-C class.
>>>> This Obj-C static uses collections to track registered events and invokes performSelector: on a registered Obj-C target.
>>>> See here:
>>>> https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBManagedEvent.m
>>>>
>>>> One of the arguments based in as part of the event callback is a pointer that is used as a a key to retrieve the target NSObject.
>>>> This is complicated by the fact that the incoming pointer represents a moveable memory location so there is some extra indirection too.
>>>> https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBPrimaryInstanceCache.m
>>>>
>>>> This can get a bit complex but its all doable.
>>>
>>> Block objects can help. clang supports block objects in plain C code (-fblocks, I think).
>>
>> They're just enabled by default on our platform in all language modes.
>>
>> John.
>>
>>> Your Objective-C code can create a block object that performs the callback and pass it to the C code to store and call. The block object would capture the target NSObject so you don't need the dictionary of callback targets.
>>>
>>>
>>> --
>>> Greg Parker email@hidden Runtime Wrangler
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> 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