Super lovely code Jonathan. My feeble brain ended up seeing if a delegate pattern would resolve this issue and it did.
The trick I am trying to achieve is simply "get the data out of the C class, the C/Obj-C glue and dump it into a more friendly structure to expose the data. Having the data container register a weak reference with the C/Obj-C glue class and then letting the data sit there and be observed by a view controller gets me where I need to be now. Ahh yes, hard mode is hard. Thanks again. On Mar 8, 2016, at 4:16 PM, Jonathan Mitchell wrote: > Alex > >> On 8 Mar 2016, at 20:59, Alex Zavatone <z...@mac.com> 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 <gpar...@apple.com> wrote: >>>> >>>> >>>>> On Mar 4, 2016, at 2:24 PM, Jonathan Mitchell <li...@mugginsoft.com> >>>>> 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 gpar...@apple.com Runtime Wrangler >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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/rjmccall%40apple.com >>>> >>>> This email sent to rjmcc...@apple.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/zav%40mac.com >>> >>> This email sent to z...@mac.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/lists%40mugginsoft.com >> >> This email sent to li...@mugginsoft.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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
