Re: KVO - deallocation with observers attached

ith non nil -observationInfo and yet it >> does not abort. >> Why does this occur? > > It's not clear to me that the KVO machinery is obligated to set > observationInfo to nil when an object is no longer being observed. Note that > observationInfo is *not* an object point

Re: KVO - deallocation with observers attached

ave instrumented my test case thoroughly and overridden > -setObservationInfo: to log the observation changes as below. > > The Data_Test object is deallocated with non nil -observationInfo and yet it > does not abort. > Why does this occur? It's not clear to me that the KVO m

KVO - deallocation with observers attached

It is common for deallocating objects to abort if they have observers still registered. However in some cases it seems that an object can get deallocated with observers attached and not abort. I have instrumented my test case thoroughly and overridden -setObservationInfo: to log the observatio

Re: Translating KVO-ed property to Swift

nt value. > > That wasn’t actually the kind of property I had in mind. I was thinking of > settable, computed properties that did not depend on the value(s) of other > KVO-observable properties. There probably aren’t many plausible *simple* > examples, but I was thinking of such

Re: Translating KVO-ed property to Swift

depend on the value(s) of other KVO-observable properties. There probably aren’t many plausible *simple* examples, but I was thinking of such cases as when the value is stored in an I/O device rather than RAM, or when the value is retrieved from a server. One problem with such examples, though, is

Re: Translating KVO-ed property to Swift

...@rivergatesoftware.com>> wrote: >>> >>> Where I disagree is in your much stronger claim that a computed property is >>> *necessarily* a dependent property. I think this is just false. The Swift >>> distinction between computed and stored properties i

Re: Translating KVO-ed property to Swift

ust false. The Swift >> distinction between computed and stored properties is syntactic and has >> nothing to do with KVO**. A KVO-observed computed property should therefore, >> according to the documented principle, be marked “dynamic”. For anyone >> following your extende

Re: Translating KVO-ed property to Swift

ll the way down to explaining how everything works >> in terms of the physics and chemistry of electrons and semiconductors, but >> that wouldn’t be very practical, would it? > > I subscribe to the principle already quoted from the documentation: If you > KVO-observe a propert

Re: Translating KVO-ed property to Swift

Just a tough that go in the ‘always use dynamic’ side. I think setter interposition is not the only issue with KVO. KVO also need to be able to fetch the old property value when -willChange: is called. I’m not sure about how it does that, but I’m pretty confident it will break if the getter is

Re: Translating KVO-ed property to Swift

iple already quoted from the documentation: If you KVO-observe a property, mark it “dynamic”. I like this because it is simple and unambiguous. If anyone asked me for advice, I’d say to follow this principle and don’t agonize any further. As a different discussion, at a different level, I agree th

Re: Translating KVO-ed property to Swift

it not >> to do. It needs the property to be dynamic for this to work. > > Yes, that’s almost exactly what I said**. But it still doesn’t make the > “dynamic” keyword an on/off switch. Again, the KVO notifications aren’t > activated *because* the method has the Swift-specific d

Re: Translating KVO-ed property to Swift

hat’s almost exactly what I said**. But it still doesn’t make the “dynamic” keyword an on/off switch. Again, the KVO notifications aren’t activated *because* the method has the Swift-specific dynamic attribute, but because the method uses Obj-C dispatching. The “dynamic” keyword [currently] forces t

Re: Translating KVO-ed property to Swift

> On Apr 19, 2017, at 4:50 PM, Quincey Morris > wrote: > >> 3. Computed properties do not need to be dynamic, […]. > > This is also not exactly true. Computed properties that have only a getter do > not need to be dynamic, because they don’t generate any KVO notificati

Re: Translating KVO-ed property to Swift

mputed properties do not need to be dynamic, […]. > > This is also not exactly true. Computed properties that have only a getter do > not need to be dynamic, because they don’t generate any KVO notifications via > a setter, and so “dynamic” is irrelevant. > > However, a computed pr

Re: Translating KVO-ed property to Swift

requirement to ensure that the property is fully in the Obj-C domain. > 3. Computed properties do not need to be dynamic, […]. This is also not exactly true. Computed properties that have only a getter do not need to be dynamic, because they don’t generate any KVO notifications via a sette

Re: Translating KVO-ed property to Swift

..@xenonium.com >> <mailto:mail...@xenonium.com>>> wrote: >>> >>> var version: String? { >> >> A slight correction: this declaration actually must be: >> >>> dynamic var version: String? { >> >> >> otherwise

Re: Translating KVO-ed property to Swift

t;mVersion = inVersion; >>[self didChangeValueForKey: @"version"]; >> } >> - >> >> Now I want to translate this method into Swift. Thing is, AFAIK you can't >> name the ivar created for a property. Is there a way to translat

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 12:03 , Charles Srstka wrote: > > You cannot guarantee that the property will be called via objc_msgSend, which > is important if you’re relying on the swizzled accessor to send the property > notifications. If you’re sending them yourself, it doesn’t matter one way or > an

Re: Translating KVO-ed property to Swift

tions > to the property accessors will use obj_msgSend, and since there’s no way in > Swift to guarantee that obj_msgSend *won’t* be used for the property, the > outcome for automatic KVO is unpredictable. You cannot guarantee that the property will be called via objc_msgSend, which

Re: Translating KVO-ed property to Swift

r inlined or devirtualized by the > compiler.” That is, unless you specify “dynamic” there’s no *guarantee* that invocations to the property accessors will use obj_msgSend, and since there’s no way in Swift to guarantee that obj_msgSend *won’t* be used for the property, the outcome for

Re: Translating KVO-ed property to Swift

n = inVersion; >[self didChangeValueForKey: @"version"]; > } > - > > Now I want to translate this method into Swift. Thing is, AFAIK you can't > name the ivar created for a property. Is there a way to translate this to > swift? I’ve been con

Re: Translating KVO-ed property to Swift

> Le 17 avr. 2017 à 10:52, Quincey Morris > a écrit : > > On Apr 17, 2017, at 01:43 , Jean-Daniel <mailto:mail...@xenonium.com>> wrote: >> >> var version: String? { > > A slight correction: this declaration actually must be: > >> dynamic va

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 01:43 , Jean-Daniel wrote: > > var version: String? { A slight correction: this declaration actually must be: > dynamic var version: String? { otherwise KVO isn’t guaranteed to work in Swift. ___ Cocoa-dev mailing li

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 01:24 , Rick Mann wrote: > > I have a number of properties in Objective-C written like this, > short-circuiting notifications when the value doesn't change: Not in this code you don’t, unless you have a “automaticallyNotifiesObserversOfVersion” method returning false elsewh

Re: Translating KVO-ed property to Swift

One way to solve that is to declare an explicit private stored property for the ivar, and a public computed property for the logic. private var _version: String? = nil var version: String? { get { return _version } set { your set version code } } > Le 17 avr. 2017 à 10:24, Rick

Translating KVO-ed property to Swift

I have a number of properties in Objective-C written like this, short-circuiting notifications when the value doesn't change: - @synthesize version = mVersion - (void) setVersion: (NSString *) inVersion { if (inVersion == nil && mVersion == nil) { return; } if

Re: Can't access by data via KVC during KVO

On Mar 27, 2017, at 14:48 , Daryle Walker wrote: > > The message observation points to the object controller’s “selection”, then a > specific property of my model (of type “String?”). >> Could not cast value of type '_NSStateMarker' (0x7fffa3003cf8) to 'NSString' >> (0x7fffa397df38). >> 2017-0

Can't access by data via KVC during KVO

data controllers. The model data is Core Data-based, BTW. I have to watch the data as part of my scheme to create a character map to use for NSTextFinder. Instead of KVO-ing the model data, I do the two data controllers instead since those are the “truth” I need to track (in case they cache any

Re: MLMediaLibrary sometimes does not call my KVO

___ 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.co

Re: MLMediaLibrary sometimes does not call my KVO

> It’s very hard for a sandboxed app to get access to the internals of Photos > without using MLMediaLibrary, though not too difficult for non-sandboxed. > MLMediaLibrary was added because of this need. I was wondering whether this API (Photos Framework aka PhotoKit) would be better suited :

Re: MLMediaLibrary sometimes does not call my KVO

in a larger UI, but it’s sufficient for many needs, and is easy to use. You could look at that and see if its behaviour is more reliable than your own code. I have tried it and it isn’t for me - I get the same problems with it that I see in NSOpenPanel, or when using KVO on MLMediaLibrary e

Re: MLMediaLibrary sometimes does not call my KVO

> I’ve run into some unreliability in MLMediaLibrary. It appears to be a bug > because it sometimes can be seen in places that use MLMediaLibrary within > general standard components, such as NSOpenPanel (this adds a media browsing > section if it is set up to allow image types, for example).

Re: MLMediaLibrary sometimes does not call my KVO

gt; referenced by them. > (Code excerpts follow at the end of this email.) > > I create an array of the top level albums at startup time of the screensaver > , using the KVO. > At runtime, I occasionally extract the images referenced by one of those > albums. > Most of the tim

MLMediaLibrary sometimes does not call my KVO

of the top level albums at startup time of the screensaver , using the KVO. At runtime, I occasionally extract the images referenced by one of those albums. Most of the time it works fine, except sometimes, my KVO never gets invoked, at which point my screensaver hangs, because I had to stop the

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

> On 20 May 2016, at 07:04, Roland King wrote: > > > Reading the original post he already has the warning about an object being > deallocated whilst still having observers attached to it. > > This is simply a case of putting a breakpoint on dealloc and working out why > the object is being

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

NSBindingDebugLogLevel on Mac OS that you can set to > 1, which will generate extra warnings about KVO and bindings. It might do > something useful in your case; I can’t remember exactly what it does, but it > may produce a warning when an object with observers gets dealloced. > >

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

uld already have a strong reference, so the object shouldn’t get dealloced unless you’ve got a ref-counting error somewhere. (Do you use ARC?) There is a user default NSBindingDebugLogLevel on Mac OS that you can set to 1, which will generate extra warnings about KVO and bindings. It might do some

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

erform this operation "get the list of files from our web end point and then download everything one file at a time asynchronously". I thought it would be fun to use KVO to observe when the downloaded file is saved into its final path and then iterate to the next item in the list. Howeve

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

Yeah, I have strong references too, but some part of my NSURLSession code ends up causing this error when we have a failure (SSL challenge) on a file download. I'll have to implement the methods to handle the download failure cases, which I am currently not doing. On May 19, 2016, at 12:57 PM,

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

> On May 19, 2016, at 9:54 AM, Alex Zavatone wrote: > > OK, fair enough. Looks like I'll have build a little weak referenced dealy > that subclasses dealloc and stops if it detects any observers. Holy crap, don’t do that. First, you can’t stop a dealloc. Instead you’d have to override retai

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

> On 19 May 2016, at 17:55, Jonathan Mitchell wrote: > > That way the observed object can get deallocated before the observer. Should say That way the observed object cannot get deallocated before the observer. J ___ Cocoa-dev mailing list (Cocoa-d

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

> > Is there any safer KVO technique to prevent or detect the dreaded "An > instance of xx was deallocated while key value observers were still > registered with it"? > I have a ton of observers in NSViewController subclasses. Generally when I use an observer

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

On May 19, 2016, at 12:41 PM, Jens Alfke wrote: > >> On May 19, 2016, at 7:51 AM, Alex Zavatone wrote: >> >> Is there a means to have an object know when it's being observed so that it >> will refuse to nuke itself in this condition? > > Nope. Remember, objects don’t “nuke” themselves; they

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

> On May 19, 2016, at 7:51 AM, Alex Zavatone wrote: > > Is there a means to have an object know when it's being observed so that it > will refuse to nuke itself in this condition? Nope. Remember, objects don’t “nuke” themselves; they are dealloced when no other objects have references to them

iOS - the joy of observers and NSInternalInconsistancyException for KVO

se to nuke itself in this condition? Sure, I can set a breakpoint on dealloc to see when this is happening, but I'm sure you lots of people have already run into this condition and have already figured out how to handle it. Is there any safer KVO technique to prevent or detect the dreaded &

Re: KVO question

consistently for all properties. I was trying to boil it down to generalities hence my dictionaryOfThings and thingy terminology, just to clarify that my understanding of KVO was correct. Seems it was. So my problem must be something specific in my code because in fact this is working for nearly

Re: KVO question

re dictionary in the > model object (it can’t do that, it doesn’t know where to find the model > object, or what the property name of the dictionary in the model object is). > > In this kind of update, Graham is expecting a KVO notification “for the > dictionary”, in order to trigge

Re: KVO question

erty name of the dictionary in the model object is). In this kind of update, Graham is expecting a KVO notification “for the dictionary”, in order to trigger keyPathsForValuesAffectingThingy. I’m saying that can’t possibly happen. ___ Cocoa-dev mailing

Re: KVO question

ham is expecting a KVO notification “for the dictionary”, in order to trigger ___ 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-adm

Re: KVO question

gt;> notifications so that the UI shows the change > > I think I understand, finally. No, what you’re doing won’t work. > > The problem is that if (say) the Font Manager has a pointer to your > NSMutableDictionary object, and mutates it — sets a new value for a key — > there *

Re: KVO question

what you’re doing won’t work. The problem is that if (say) the Font Manager has a pointer to your NSMutableDictionary object, and mutates it — sets a new value for a key — there *will* be a KVO notification** — I believe we know that the standard NSMutableDictionary class issues KVO notificatio

Re: KVO question

ws the change. The dictionary is being changed in a KVO compliant way, because the entire dictionary is updated and replaced as a whole - the settings within the dictionary are not mutated individually. —Graham ___ Cocoa-dev mailing list (Cocoa-de

Re: KVO question

possible workaround would be to replace `self.dictionaryOfThings = temp;` with `_dictionaryOfThings = temp;`. Gerd > > On Nov 17, 2015, at 19:18, Graham Cox wrote: > > I’m using KVO to observe a bunch of properties. > > Most of these properties are split out into simple

Re: KVO question

Are you implying that one KVO is blocking the others? Sent from my iPhone > On Nov 17, 2015, at 8:18 PM, Graham Cox wrote: > > I’m using KVO to observe a bunch of properties. > > Most of these properties are split out into simple things that set a single > value, but int

Re: KVO question

On Nov 17, 2015, at 7:18 PM, Graham Cox wrote: > > I’m using KVO to observe a bunch of properties. > > Most of these properties are split out into simple things that set a single > value, but internal to my object, some end up setting a common dictionary of > attribute

Re: KVO question

the additional triggering. Have I understood that right? It’s not clear. I can’t think of a compelling reason why the other observers shouldn’t trigger, but you are doing something a bit weird. I wonder, also, if you’re always setting the ‘dictionaryOfThings’ property KVO-compliantly? In par

Re: KVO question

It seems like it *should* work. Are you sure you don’t have a typo in your addObserver: method? Considering that you’re using the dictionary’s property setter, keyPathsForValuesAffecting shouldn’t even be necessary. When I apply KVO, I try to mitigate the potential unsafely of key paths

KVO question

I’m using KVO to observe a bunch of properties. Most of these properties are split out into simple things that set a single value, but internal to my object, some end up setting a common dictionary of attributes, which is also a property. I KVO observe both the simple properties and the common

Re: KVO detection of changes to selection in NSOpenPanel

king on 10.8. Does anyone know if there’s any hope of my KVO approach > working? No. If a property is not explicitly documented to be KVO-compliant, you must assume that it isn't. The alternative seems to be to implement a delegate method for > panelSelectionDidChange. Would that be the se

KVO detection of changes to selection in NSOpenPanel

lue Observation compliance was dramatically increased for public and > some private properties of actual, non sandboxed NSOpen and Save panels, > including keys affecting other values. For example, if the directory value > changes on a save panel, this will cause a KVO notification to be

Re: Assuring KVO compliance.

On Apr 7, 2015, at 3:13 PM, Jens Alfke wrote: > >> On Apr 7, 2015, at 7:04 AM, Alex Zavatone wrote: >> >> The code that I've inherited has an enum (not an NSEnum) that represents the >> app's connected state, 0, 1 or 2. > > There’s no difference. NS_ENUM is just a macro that defines a C enum

Re: Assuring KVO compliance.

> On Apr 7, 2015, at 7:04 AM, Alex Zavatone wrote: > > The code that I've inherited has an enum (not an NSEnum) that represents the > app's connected state, 0, 1 or 2. There’s no difference. NS_ENUM is just a macro that defines a C enum, but uses some newer (C99?) syntax to specify the intege

Re: Assuring KVO compliance.

On Apr 7, 2015, at 09:05 , Alex Zavatone wrote: > > Gremlins, I think. No, something, but not that. Enums are a C thing, not even Obj-C. They are, for all intents and purposes, an int of some size and signedness chosen by the compiler. So, the enum part of this is a red herring. The reason th

Re: Assuring KVO compliance.

"OK, I'm going to believe the debugger and try to make sure I address KVO/KVC compliance on the observed and make sure that the property is about to be observed and changed by multiple sources". So, I tried what I thought would be good practices. Make sure the enum is backed

Re: Assuring KVO compliance.

> I was just looking at some of my own code because I’m pretty sure I use enums all the time in properties which are KVO and observe them and update them, and I’ve never once had to mess around with NS_ENUM to make them work. And indeed I found 4 examples quite quickly, all of which look v

Re: Assuring KVO compliance.

, APP_State_Waiting = 2 }; Changing the atomicity of the exposed property had no effect on whether the exception was issued or not. Hope this helps someone. Alex Zavatone On Apr 7, 2015, at 10:04 AM, Alex Zavatone wrote: > I've read Apple's docs on assuring KVO/KVC compliance, but in th

Assuring KVO compliance.

I've read Apple's docs on assuring KVO/KVC compliance, but in this particular situation, I'd appreciate someone explaining what I'm not getting here if it's anything obvious. I think what I'm asking is how to convert code that has a state exposed as a (nonat

Re: Core Data To-Many Relationship KVO

> On Feb 11, 2015, at 5:36 PM, Roland King wrote: > > processPendingChanges:, it’s on NSManagedObjectContext That’s what I was looking for. Thanks for your help. Richard Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do no

Re: Core Data To-Many Relationship KVO

> On 12 Feb 2015, at 08:27, Richard Charles wrote: > > >> On Feb 11, 2015, at 4:51 PM, Roland King wrote: >> >> committing the core data changes removes them from all the relationships and >> fires KVO changes. see propagatesDeletesAtEndOfEvent: and &

Re: Core Data To-Many Relationship KVO

> On Feb 11, 2015, at 4:51 PM, Roland King wrote: > > committing the core data changes removes them from all the relationships and > fires KVO changes. see propagatesDeletesAtEndOfEvent: and > commitPendingChanges. In AppKit usually deletes are propagated once around >

Re: Core Data To-Many Relationship KVO

> On 12 Feb 2015, at 07:27, Richard Charles wrote: > > I have a Core Data in-memory store. There is a managed object which uses KVO > on a to-many relationship property of itself. > > When an object at the other end of the relationship is deleted using >

Core Data To-Many Relationship KVO

I have a Core Data in-memory store. There is a managed object which uses KVO on a to-many relationship property of itself. When an object at the other end of the relationship is deleted using [managedObjectContext deleteObject:object] the KVO change notification is not sent right away. What

OS X 10.10 KVO default behaviour change when observers not removed

Jens mentioned in a previous thread that he was not quite sure whether to always remove observations or not. This was bugging me. I always did it, though more out of habit than absolute conviction. The code below confirms that not removing the observation prior to deallocating the observing obje

Re: Self KVO...

the control ever gets -setValue:forKey: when the > property to which it is bound changes. That's one possible way for the > implementation to work, but as least as likely is for the control to have > -observeValueForKeyPath:… to be called on it because it was using KVO to > ob

Re: Self KVO...

he implementation to work, but as least as likely is for the control to have -observeValueForKeyPath:… to be called on it because it was using KVO to observe the property to which it is bound. In any case, the cell should be entirely insulated from the way in which the control received its new

Self KVO...

I’m not sure I am having a hard time figuring this out and I am just not finding anything via Google. I am writing a NSTextFieldCell subclass and I want to recalculate the size whenever the string value changes via a binding. What I can’t seem to figure out is how to observe the change. I cou

Re: Extending KVO to scalar struct types?

On 29 Aug 2014, at 3:56 pm, Graham Cox wrote: > You might wonder if I already know the type why this is even useful. Having given this a lot more thought, I think it's simpler just to break down the compound properties into singular ones on the target object. These can be derived from the co

Re: Extending KVO to scalar struct types?

On 29 Aug 2014, at 3:48 pm, Graham Cox wrote: > I already know that a given property of a given object is a CGSize (say) You might wonder if I already know the type why this is even useful. In a UI, different controls might set values independenty such as the x and y of a point. Each control

Re: Extending KVO to scalar struct types?

On 29 Aug 2014, at 3:20 pm, Quincey Morris wrote: > {=… > > which you can use to figure out what you need. This is much what I'm doing, but it's a bit simpler - I don't need to introspect the property details of the target object, since I know that -valueForKey: will return scalar types wr

Re: Extending KVO to scalar struct types?

On Aug 28, 2014, at 21:09 , Graham Cox wrote: > Actually that will work for me. I only need to support size, points and rects > at the moment, so it's easy enough to use the -objCType to see which one I > have and then just change the field according to which specific string I > pass. A catego

Re: Extending KVO to scalar struct types?

On 29 Aug 2014, at 1:52 pm, Ken Thomases wrote: > In case you're not aware, certain Core Animation classes have support for > this sort of thing: Core Animation Programming Guide: Key-Value Coding > Extensions – Key Path Support for Structures. >

Re: Extending KVO to scalar struct types?

On Aug 28, 2014, at 10:25 PM, Graham Cox wrote: > I had an idea that could simplify quite a bit of tedious glue code, but I'm > not sure if it's feasible. > > -[NSObject setValue: forKeyPath:] can take a key path for any property, but > not for fields of that property if it's a scalar struct t

Re: Extending KVO to scalar struct types?

> On Aug 28, 2014, at 8:25 PM, Graham Cox wrote: > > The problem here is being able to get to the struct's field at runtime given > its name as a string. Is that even possible? Not in C. The closest you can get is the @encode(…) directive, which at compile-time evaluates to the type-encoding

Extending KVO to scalar struct types?

Hi all, I had an idea that could simplify quite a bit of tedious glue code, but I'm not sure if it's feasible. -[NSObject setValue: forKeyPath:] can take a key path for any property, but not for fields of that property if it's a scalar struct type, e.g. @"myObject.location.x" isn't allowed if

Re: value in KVO change dictionary ?

bject selectedObjects]'. So why is this object not in the change > dictionary? This is a long-standing issue with array controllers. The KVO change notifications never include the new or old values, regardless of the KVO options to request them. You just have to query the object via the k

value in KVO change dictionary ?

Hello, I'm puzzled by a problem that I am seeing with key value observing an arraycontroller and I'm hoping that someone here could shed some light. Here's the situation: I have a nib with a panel that contains a collectionview and an arraycontroller. It's like some Tool panel in a drawing app

Re: How can an instance KVO its own and super's attributes, especially with overrides?

On Aug 20, 2014, at 11:02 PM, Daryle Walker wrote: > I’m writing an NSOperation subclass. Instances are dumped into the main > queue, but I hope I stop them from executing right away by overriding > -isReady. But the docs say I have to keep the override KVO-compliant. And my > for

How can an instance KVO its own and super's attributes, especially with overrides?

I’m writing an NSOperation subclass. Instances are dumped into the main queue, but I hope I stop them from executing right away by overriding -isReady. But the docs say I have to keep the override KVO-compliant. And my formula for the new -isReady uses the old one. Can I observe on super

Re: When would I use this (im)mutable property pair setup? (Misunderstanding advanced KVO)

[_windowControllers intersectSet:controllers]; > } No, you don’t need this, or any other accessors. If you do everything else right, any client invocation of (say) ‘[myAppDelegate.mutableWindowControllers intersectSet: controllers];’ will get automatically translated into a c

When would I use this (im)mutable property pair setup? (Misunderstanding advanced KVO)

o just a mutable-set property? (Delete the current “windowControllers” and rename the mutable variant.) But the text seemed like that would mess up KVO in a different way. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com __

Re: KVO query

cation from the > underlying API that something has changed, you fetch the new object from that > API and assign it to self.status. That assignment is KVO-compliant. You > can/should then eliminate your manual -will/didChange… invocations. > That all makes sense. I am effectively

Re: KVO query

On 13 Aug 2014, at 23:41, Quincey Morris wrote: > On Aug 13, 2014, at 14:53 , Jonathan Mitchell wrote: > >> At one point i need to invoke a manual KVO notification like so: >> >> [submission willChangeValueForKey:@“status”]; >> [submission didChangeValueForKey:

Re: KVO query

On Aug 13, 2014, at 14:53 , Jonathan Mitchell wrote: > At one point i need to invoke a manual KVO notification like so: > > [submission willChangeValueForKey:@“status”]; > [submission didChangeValueForKey:@“status”]; > > This raises like so: > > Terminating app d

Re: KVO query

On Aug 13, 2014, at 4:53 PM, Jonathan Mitchell wrote: > I have a key path like so which is observed: > > submission.status.name > > At one point i need to invoke a manual KVO notification like so: > > [submission willChangeValueForKey:@“status”]; > [submission didCh

Re: KVO query

Have you implemented +automaticallyNotifiesObserversForKey: and returned NO for “status” ? On Aug 13, 2014, at 2:53 PM, Jonathan Mitchell wrote: > I have a key path like so which is observed: > > submission.status.name > > At one point i need to invoke a manual KVO notif

KVO query

I have a key path like so which is observed: submission.status.name At one point i need to invoke a manual KVO notification like so: [submission willChangeValueForKey:@“status”]; [submission didChangeValueForKey:@“status”]; This raises like so: Terminating app due to uncaught exception

Re: viewDidLoad and KVO

; If you're doing something like this: >>> >>> - (void)setFoo: (Foo *)aFoo >>> { >>> [foo removeObserver:self forKeyPath:@"whatever"...]; >>> foo = aFoo; >>> [foo addObserver:self forKeyPath:@"whatever"...; >>> } >

Re: viewDidLoad and KVO

foo' at that time. As far as observing 'foo' via KVO, the way I generally like to do this is to have my VC implement methods that have the exact same form (as setters) as the properties they're interested in on the model object, then my observer method boils down to

Re: viewDidLoad and KVO

...; >> } >> >> we used that pattern for a while but were constantly getting bit by >> observers on objects being dealloced or KVO firing and triggering unwanted >> side effects if we called setFoo: in dealloc. So we did a complete switch >> over to doin

Re: viewDidLoad and KVO

> } > > we used that pattern for a while but were constantly getting bit by observers > on objects being dealloced or KVO firing and triggering unwanted side effects > if we called setFoo: in dealloc. So we did a complete switch over to doing > > [self addObserver:self forKey

  1   2   3   4   5   6   7   8   >