My services in my own app
Hi, My app registers some services and they work just fine. Only if I invoke then from within the same application, the app hangs. I tried with other apps and they had the same problem. I searched the web for it but could not find anything. Is there anything I can do about it? Thanks Georg___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: My services in my own app
You didn't indicate what version of Mac OS X you were running under. If this is happening under Snow Leopard, then this is a known issue in Snow Leopard that Apple fixed in Lion. The only work around I know is to put the service code in a separate (background) application that then calls back into your app to do whatever task you need it to do. Mark On Sun, Jan 15, 2012 at 9:09 AM, Georg Seifert georg.seif...@gmx.de wrote: Hi, My app registers some services and they work just fine. Only if I invoke then from within the same application, the app hangs. I tried with other apps and they had the same problem. I searched the web for it but could not find anything. Is there anything I can do about it? Thanks Georg___ 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: http://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com This email sent to unmar...@gmail.com -- Mark Munz unmarked software http://www.unmarked.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Application badge (like Mail) in views other than the doc icon?
Hi Everyone, My app has an NSCollectionView of devices, each with a custom icon. I have a need to display the number of downloads happening from a given device. The way that I want to do this, is to place a badge on each icon. I have just tried to implement a clone of the NSDockTile badge that Mail uses. Needless to say, it isn't a perfect match.. :) I was wondering if anyone out there has been able to coax setBadgeLabel to draw on a custom NSView, rather than the dockTile? Could I do something like this: (typed into the email.. errors are likely) [[NSApp dockTile] setContentView:myCustomView]; [[NSApp dockTile] setBadgeLabel:@20]; [[NSApp dockTile] setContentView:nil]; Would this end up causing weirdness with my App's icon? (Or should I stick to my own routines for drawing a badge?) Thanks! bob. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Correct way to force reading property from sql store?
On Jan 14, 2012, at 2:35 PM, Jerry Krinock wrote: I want my app to access the new value of an object's property stored in an sqlite store, after this value has been modified on disk by another process. A few weeks ago, I did this, and I thought it was working: [[obj managedObjectContext] refreshObject:self mergeChanges:YES] ; id foo = [obj foo] ; I don't know that I have anything useful to say but the fact that you are trying to fault an object inside the object itself seems like a code smell. Or do you mean to instead do: [[obj managedObjectContext] refreshObject: obj mergeChanges:YES] ; Do you experience the same behavior if you refresh the object from a point outside the object, also making sure that it is not retained by anything outside the MOC? However, upon retesting today I found that foo was the old value, and after puzzling over the documentation of -[NSManagedObject refreshObject:mergeChanges:], and some experimentation, I fixed it by doing this instead: [[obj managedObjectContext] processPendingChanges] ; // just in case NSTimeInterval oldStaleness = [[obj managedObjectContext] stalenessInterval] ; [[obj managedObjectContext] setStalenessInterval:0.0] ; [[obj managedObjectContext] refreshObject:self mergeChanges:NO] ; id foo = [obj foo] ; [[obj managedObjectContext] setStalenessInterval:oldStaleness] ; By the way, oldStaleness is the default value of -1.0. Is there a better way? It seems like gimme the latest value of object.foo from the disk shouldn't be so hard. If all you read is the first line of that documentation [1], you think that it is easy! Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: music.read-only sandbox entitlement doesn't seem to work
I tried replacing my Core Audio code for reading and decoding the music files with calls to the AV Foundation framework. I was hoping that the defunct assets.music.read-only entitlement would begin working if I used AV Foundation instead. No joy. AVAsset cannot read the file (NO == asset.readable) without the temporary path entitlement in place. -Michael On Jan 9, 2012, at 12:52 PM, Michael Crawford wrote: I'm converting over a legacy Core-Audio application to run sandboxed. This app normally access files in the iTunes library in order to analyze them for BPM information. Enabling the music.read-only entitlement does not work. com.apple.security.assets.music.read-only I get the following error: deny file-read-data /Users/smj/Music/iTunes/iTunes Music/Depeche Mode/Violator/01 World In My Eyes.mp3 I have been able to overcome this problem by adding the temporary exception to perform relative reads from the users home directory using this path: /Music/iTunes/iTunes Music/ My issue with this solution is that it is temporary! Can anyone shed light on why the music entitlement is not working? As I indicated I'm using Core Audio APIs. Do I need to switch to AVAsset or something like this to make this work? Some other little detail I'm leaving out? One other thought that just occurred to me is that I'm using the paths I get from iTunes to try and access these files. These paths are absolute from the root directory and look something like this: Unable to open track file://localhost/Users/michael/Music/iTunes/iTunes%20Music/Depeche%20Mode/Violator/01%20World%20In%20My%20Eyes.mp3 (File not found) Do I need to specify some sort of relative substitute when using *.music.read-only? -Michael ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/michaelacrawford%40me.com This email sent to michaelacrawf...@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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Correct way to force reading property from sql store?
Hi Jerry, On 16 Jan 12 Jerry Krinock je...@ieee.org wrote: It seems like gimme the latest value of object.foo from the disk shouldn't be so hard. It is indeed that hard, possibly for a good reason, but let's not go into that. You've correctly handled the staleness interval. You may also want to save the current staleness interval and restore it after you refresh the object. What you've discovered, and what Apple confirmed for me long ago, is that refreshObject does not refresh related objects. As surprised as I was to learn that, it now makes some sense. You're on the right track. Cheers, Steve___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Is slowing down bindings updates possible?
I'm not sure if this has already been suggested: What if you don't update the UI unless the change is at least 1 sec or 1% or certain amount of bytes (whatever suits your needs better)? Leo On 1/15/12 12:33:31 AM, Andrew wrote: Thank you all for the opinions. I left the code as-is in terms of binding, but changed my rate calculations to use a weighted running average. After doing so, the estimated seconds tick by one at a time for the most part, and the rate is more constant. This is a tool for me and some co-workers, so at this point, it is good enough. But the ideas are sound and if it bothers me enough, I may decouple the UI from the model by not using bindings at some point and use a timer based approach. On Sat, Jan 14, 2012 at 10:37 AM, Kyle Sluderkyle.slu...@gmail.com wrote: On Jan 14, 2012, at 2:53 AM, Marcel Weihermarcel.wei...@gmail.com wrote: Hi Andrew, On Jan 13, 2012, at 6:57 , Andrew wrote: The result of this is that the UI updates really frequently and the estimated time to complete and the download rate jump around a lot. I would love it if I could tell cocoa to only update the UI once per second instead of immediately when the property key changes. You shouldn't push updates to the UI, the UI should query the model, and it should do it at human speed, not at whatever speed the machine can manage to change the state. There are a bunch of reasons for this, not least is that UI updating is fairly heavyweight and you can actually impact your performance (significantly, in some cases). Be careful here. This is good advice in this particular circumstance, but in general pushing values to the UI is good and common design. The UI will register as a KVO observer, or as an NSNotification observer, or perhaps the controller will just call -setObjectValue: directly. Breaking this pattern should be a conscious decision. For example, you don't push a value to cell-based NSTableViews; you tell the table view it needs to ask you for the values at certain indexes. This is because cell-based table views are an optimization that avoids keeping tons of view objects around. But view-based table views behave just like any other view: you push updates directly to the controls contained within your table cell view. In Andrew's case, it's clear that he should deviate from the norm, and the UI should be in charge of asking for the latest value at a rate that makes sense, probably controlled by an NSTimer. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/leo.r%40rogers.com This email sent to le...@rogers.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
KVO willChange and didChange
Hi all, when I declare a property, something like:
@property(readwrite, copy, nonatomic) NSString *foo;
I will synthesize it with:
@synthesize foo;
But then I want to do some special processing when the value is set, so I
implement my setter:
- (void)setFoo:(NSString *)aFoo {
[self willChangeValueForKey:@foo];
[foo autorelease];
foo = [aFoo retain];
[self didChangeValueForKey:@foo];
[self
doSomeMoreProcessingThatShouldHappenAfterAllTheObserversKnowTheNewValue];
}
I assumed from the documentation and examples that since I was providing my own
implementation method, that I would have to include the willChange and
didChange methods at appropriate points in my code, but I have just discovered
that when I do:
anObject.foo = @something;
I get two prior notifications - one from the internals of the system, and one
from my willChange call, and two notifications after the change - one from my
didChange and one from the system.
So I thought this must because I used @synthesize as well as providing my own
method, so I implemented a getter and removed the @synthesize. The behavior
didn't change.
I double checked this by removing my willChange and didChange methods, and now
the prior and after notifications only got sent once.
One purpose of mentioning this is that given the fact that I have come across
code from several places where they did what I did and had the willChange and
didChange code in their setters, others may need to look back at their code and
make appropriate changes.
But the big thing for me is that I have a number of places throughout my
application where I need to have the changes made, the didChange notification
acted on by the observers, and then some other code run.
I therefore wanted to use the setter, but not have to change the name of it, so
that bindings would still work, so I changed my property declaration to be
readonly, and declared a setFoo: method. I thought that declaring it would make
it not call the willChange and didChange behind the scenes, but unfortunately,
even with a readonly declaration, when I used anObject.foo = @something, it
still called the prior and after KVO methods. So I thought I would explicitly
call setFoo: instead of using dot notation, but that made no difference. On the
off chance there was something else going on, I also turned off
accessesInstanceVariablesDirectly, but that made no difference.
So I thought I would just remove the property declarations altogether, and just
code my accessors myself, but it still called the built in KVO methods.
Therefore my conclusion is that as soon as you add a KVO observation on
anything, it triggers the prior and after notifications whenever the setter is
called. This of course makes sense, but still leaves me with the original
problem: I need some way to have the KVO notifications called *once only*, and
yet have my setters able to call other methods after the KVO notifications have
been sent. It is not possible for this to be done with
performSelector:withObject:afterDelay: or anything similar, since these methods
need to be called immediately after the after change notification.
I know I could get it to call the KVO notifications at only the right places by
coding my own methods like -(void)changeFooTo:, but I do not want to change the
name of my setters because that would break my bindings.
Are there any recommendations on the best approach for being able to have the
setter able to do what it needs with the KVO and then calling other methods,
without breaking bindings?
I can't believe I have misunderstood this for so long, and never noticed what
was happening until now!
Thanks
Gideon
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
Read the section Automatic Change Notification again and understand it has
nothing to do with properties or dot notation but just the method name.
Then look up automaticallyNotifiesObserversForKey and turn it off if you want
to code one key fully manually.
On 16 Jan, 2012, at 14:30, Gideon King gid...@novamind.com wrote:
Hi all, when I declare a property, something like:
@property(readwrite, copy, nonatomic) NSString *foo;
I will synthesize it with:
@synthesize foo;
But then I want to do some special processing when the value is set, so I
implement my setter:
- (void)setFoo:(NSString *)aFoo {
[self willChangeValueForKey:@foo];
[foo autorelease];
foo = [aFoo retain];
[self didChangeValueForKey:@foo];
[self
doSomeMoreProcessingThatShouldHappenAfterAllTheObserversKnowTheNewValue];
}
I assumed from the documentation and examples that since I was providing my
own implementation method, that I would have to include the willChange and
didChange methods at appropriate points in my code, but I have just
discovered that when I do:
anObject.foo = @something;
I get two prior notifications - one from the internals of the system, and one
from my willChange call, and two notifications after the change - one from my
didChange and one from the system.
So I thought this must because I used @synthesize as well as providing my own
method, so I implemented a getter and removed the @synthesize. The behavior
didn't change.
I double checked this by removing my willChange and didChange methods, and
now the prior and after notifications only got sent once.
One purpose of mentioning this is that given the fact that I have come across
code from several places where they did what I did and had the willChange and
didChange code in their setters, others may need to look back at their code
and make appropriate changes.
But the big thing for me is that I have a number of places throughout my
application where I need to have the changes made, the didChange notification
acted on by the observers, and then some other code run.
I therefore wanted to use the setter, but not have to change the name of it,
so that bindings would still work, so I changed my property declaration to be
readonly, and declared a setFoo: method. I thought that declaring it would
make it not call the willChange and didChange behind the scenes, but
unfortunately, even with a readonly declaration, when I used anObject.foo =
@something, it still called the prior and after KVO methods. So I thought I
would explicitly call setFoo: instead of using dot notation, but that made no
difference. On the off chance there was something else going on, I also
turned off accessesInstanceVariablesDirectly, but that made no difference.
So I thought I would just remove the property declarations altogether, and
just code my accessors myself, but it still called the built in KVO methods.
Therefore my conclusion is that as soon as you add a KVO observation on
anything, it triggers the prior and after notifications whenever the setter
is called. This of course makes sense, but still leaves me with the original
problem: I need some way to have the KVO notifications called *once only*,
and yet have my setters able to call other methods after the KVO
notifications have been sent. It is not possible for this to be done with
performSelector:withObject:afterDelay: or anything similar, since these
methods need to be called immediately after the after change notification.
I know I could get it to call the KVO notifications at only the right places
by coding my own methods like -(void)changeFooTo:, but I do not want to
change the name of my setters because that would break my bindings.
Are there any recommendations on the best approach for being able to have the
setter able to do what it needs with the KVO and then calling other methods,
without breaking bindings?
I can't believe I have misunderstood this for so long, and never noticed what
was happening until now!
Thanks
Gideon
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
This email sent to r...@rols.org
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
On Mon, Jan 16, 2012 at 12:30 AM, Gideon King gid...@novamind.com wrote: Are there any recommendations on the best approach for being able to have the setter able to do what it needs with the KVO and then calling other methods, without breaking bindings? I can't believe I have misunderstood this for so long, and never noticed what was happening until now! From the KVO programming guide, Manual Change Notification: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOCompliance.html#//apple_ref/doc/uid/20002178-SW3 ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
Try overriding +[NSObject(NSKeyValueObserving)
automaticallyNotifiesObserversForKey:] to return NO for the properties you want
to handle manually.
On 2012-01-16, at 01:30, Gideon King wrote:
Hi all, when I declare a property, something like:
@property(readwrite, copy, nonatomic) NSString *foo;
I will synthesize it with:
@synthesize foo;
But then I want to do some special processing when the value is set, so I
implement my setter:
- (void)setFoo:(NSString *)aFoo {
[self willChangeValueForKey:@foo];
[foo autorelease];
foo = [aFoo retain];
[self didChangeValueForKey:@foo];
[self
doSomeMoreProcessingThatShouldHappenAfterAllTheObserversKnowTheNewValue];
}
I assumed from the documentation and examples that since I was providing my
own implementation method, that I would have to include the willChange and
didChange methods at appropriate points in my code, but I have just
discovered that when I do:
anObject.foo = @something;
I get two prior notifications - one from the internals of the system, and one
from my willChange call, and two notifications after the change - one from my
didChange and one from the system.
So I thought this must because I used @synthesize as well as providing my own
method, so I implemented a getter and removed the @synthesize. The behavior
didn't change.
I double checked this by removing my willChange and didChange methods, and
now the prior and after notifications only got sent once.
One purpose of mentioning this is that given the fact that I have come across
code from several places where they did what I did and had the willChange and
didChange code in their setters, others may need to look back at their code
and make appropriate changes.
But the big thing for me is that I have a number of places throughout my
application where I need to have the changes made, the didChange notification
acted on by the observers, and then some other code run.
I therefore wanted to use the setter, but not have to change the name of it,
so that bindings would still work, so I changed my property declaration to be
readonly, and declared a setFoo: method. I thought that declaring it would
make it not call the willChange and didChange behind the scenes, but
unfortunately, even with a readonly declaration, when I used anObject.foo =
@something, it still called the prior and after KVO methods. So I thought I
would explicitly call setFoo: instead of using dot notation, but that made no
difference. On the off chance there was something else going on, I also
turned off accessesInstanceVariablesDirectly, but that made no difference.
So I thought I would just remove the property declarations altogether, and
just code my accessors myself, but it still called the built in KVO methods.
Therefore my conclusion is that as soon as you add a KVO observation on
anything, it triggers the prior and after notifications whenever the setter
is called. This of course makes sense, but still leaves me with the original
problem: I need some way to have the KVO notifications called *once only*,
and yet have my setters able to call other methods after the KVO
notifications have been sent. It is not possible for this to be done with
performSelector:withObject:afterDelay: or anything similar, since these
methods need to be called immediately after the after change notification.
I know I could get it to call the KVO notifications at only the right places
by coding my own methods like -(void)changeFooTo:, but I do not want to
change the name of my setters because that would break my bindings.
Are there any recommendations on the best approach for being able to have the
setter able to do what it needs with the KVO and then calling other methods,
without breaking bindings?
I can't believe I have misunderstood this for so long, and never noticed what
was happening until now!
Thanks
Gideon
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/gordonhenriksen%40me.com
This email sent to gordonhenrik...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
Cool, thanks everybody. Nice that there is such a simple solution. Regards Gideon On 16/01/2012, at 4:41 PM, Gordon Henriksen wrote: Try overriding +[NSObject(NSKeyValueObserving) automaticallyNotifiesObserversForKey:] to return NO for the properties you want to handle manually. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
On Jan 15, 2012, at 10:41 PM, Gordon Henriksen wrote: Try overriding +[NSObject(NSKeyValueObserving) automaticallyNotifiesObserversForKey:] to return NO for the properties you want to handle manually. Or just don’t call will/DidChange in your setter methods. You don’t need them there — KVO automatically does that for you when a setter is called. What will/DidChange are for is when you change a property’s value without invoking its setter. So if you had some code elsewhere that caused the value of the .foo property to change, you’d wrap those methods around the change. Obviously in your case you should just call setFoo instead, but there are cases when a property’s value isn’t stored explicitly as a variable, but is computed by the accessor method. So there’s no explicit variable and no sense in having a setter, but the value of the getter does change, and you have to let KVO know that. —Jens___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KVO willChange and didChange
You missed this in the original mail. But the big thing for me is that I have a number of places throughout my application where I need to have the changes made, the didChange notification acted on by the observers, and then some other code run. Which is why he wants to manually emit KVO notifications in a standardly-named setter so he can put more code after the didChangeValueForKey: before the setter returns. I'd say having code which depends on that ordering is a bit suspect, but if that's what he wants, removing the automatic notifications and doing it himself is ok. On 16 Jan, 2012, at 15:13, Jens Alfke j...@mooseyard.com wrote: On Jan 15, 2012, at 10:41 PM, Gordon Henriksen wrote: Try overriding +[NSObject(NSKeyValueObserving) automaticallyNotifiesObserversForKey:] to return NO for the properties you want to handle manually. Or just don’t call will/DidChange in your setter methods. You don’t need them there — KVO automatically does that for you when a setter is called. What will/DidChange are for is when you change a property’s value without invoking its setter. So if you had some code elsewhere that caused the value of the .foo property to change, you’d wrap those methods around the change. Obviously in your case you should just call setFoo instead, but there are cases when a property’s value isn’t stored explicitly as a variable, but is computed by the accessor method. So there’s no explicit variable and no sense in having a setter, but the value of the getter does change, and you have to let KVO know that. —Jens___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
