Re: Problem with NSColor since 10.2
Re: Problem with NSColor since 10.2
- Subject: Re: Problem with NSColor since 10.2
- From: Ondra Cada <email@hidden>
- Date: Wed, 28 Aug 2002 16:51:13 +0200
On Wednesday, August 28, 2002, at 04:37 , Frank Blome wrote:
allowColor = [defaults objectForKey: @"AllowColor"];
if (allowColor == nil)
allowColor = [NSArchiver archivedDataWithRootObject:[NSColor
blueColor]];
Suspicious: since allowColor is not an automatic variable, it seems you
should retain. (Also it would seem to be better to keep the NSColor
locally, not the archived NSData, but of course you might have strong
reasons for that.)
It will released in "applicationWillTerminate" - this is the only thing
that I do before quitting the Application.
Nope, applicationWillTerminate is uninteresting. What *is* interesting is
that both objectForKey: and archivedDataWithRootObject: return an
*autoreleased* object, and thus, unless retained, the allowColor contents
may be lost when the current autorelease pool is released.
The reason to store it in a NSData is because the color will/can change
often, so it is easier to save them (there are 4 diffreent colors) in the
preferences, I believe.
I stil don't see, but that's not important.
Short of memory management,
What did you mean with it?
What I've written above.
it looks right. What's the matter?
It crashed with signal 11 (SIGSEGV). But when I use the predefined Colors
(i.e. [NSColor blueColor]) everything works fine...
Presumably predefined colours are shared objects, and thus never
deallocated: such behaviour perfectly matches the memory management bug I'
ve pointed out.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.