Re: Crash when color well panel is open
Re: Crash when color well panel is open
- Subject: Re: Crash when color well panel is open
- From: Keith Wilson <email@hidden>
- Date: Fri, 10 Feb 2006 01:38:55 +1100
MyView does not own a reference to NSColorWell
I assumed that you had dropped the ColorWell onto a CustomView of
class MyView.
Keith
On 09/02/2006, at 1:11 AM, Justin Gullingsrud wrote:
Hi,
On 2/8/06, Keith Wilson <email@hidden> wrote:
Looks circular to me.
MyView owns bgColor and its subview the NSColorWell is bound via
MyDocument to bgColor which is owned by MyView....
Sorry, I should have made this more clear. MyView does not own a
reference to NSColorWell; in fact there are no IBOutlets for it,
only for MyView.
My new theory about what's going on here is that, when
NSColorWell's color panel is open, NSColorWell gets an extra retain
that it doesn't have when the panel isn't open (recall that the
crash happens only when I close the document window while the panel
is open). Does that sound plausible?
It looks like what I ought to be doing is something like your
second suggestion of binding NSColorWell to some instance, which in
my app will be a managed object made manifest in the nib by an
object controller. The persistent document will have a MyView
outlet, and update the view when it observes a changes in the value
that the color well is updating.
Thanks for your suggestions,
Justin
This is OK when you Quit the app but what happens when you simply
close the document window?
You do not really need to write methods for bgColor and setBgColor.
If needed you could use setValue:forKey: in your awakeFromNib to set
the initial color value.
If you move NSColor *bgColor; from the @interface for MyView to be
owned by MYDocument then it will work fine.
Or maybe bind bgColor to SharedUserDefaults and then access it (when
needed fro drawing) but a for color you will need to archive it in
UserDefaults using something like
-(void)setBgColor:(NSColor*)newBgColour
{
[newBgColor retain];
[BgColor release];
BgColor = newBgColor;
NSUserDefaults *userDefaults = [NSUserDefaults
standardUserDefaults];
[userDefaults setObject:[NSArchiver
archivedDataWithRootObject:BgColor] forKey:@"bgColor"];
}
and then unarchive it when you need it using
NSUserDefaults *userDefaults = [NSUserDefaults
standardUserDefaults];
NSData *data = [userDefaults dataForKey:@"bgColor"];
if(data)
[self setBgColor:(NSColor*)[NSUnarchiver
unarchiveObjectWithData:data]];
else
.....
Keith from DownUnder
On 08/02/2006, at 5:57 PM, Justin Gullingsrud wrote:
> Some of my apps are crashing when I close a document when a color
> well is
> still open and observing a view. I've made a very simple test
> program that
> reproduces this reliably. The program is:
> - Cocoa document-based application
> - Create a subclass of NSView called MyView; give it bgColor and
> setBgColor
> methods that return red or do nothing, respectively.
> - MyDocument contains an outlet for an instance of MyView;
> - MyDocument.nib contains a window with a MyView and an
> NSColorWell. The
> value of the color is bound to myView.bgColor in Files Owner,
which is
> MyDocument.
>
> If I start this app and close the document window, nothing happens,
> but if I
> close it after first activating the color well, I get a crash and
the
> following error message:
> An instance 0x35c4a0 of class MyView is being deallocated while key
> value
> observers are still registered with it. Break on
> _NSKVODeallocateLog to
> start debugging.
>
>
> Here are the gory details:
> gdb) where
> #0 0xfffeff20 in objc_msgSend_rtp ()
> #1 0x9296c778 in -[NSObject(NSKeyValueObserverRegistration)
> removeObserver:forKeyPath:] ()
> #2 0x938b54d8 in -[NSBinder _updateObservingRegistration:] ()
> #3 0x93b4c3a4 in -[NSBinder
> releaseConnectionWithSynchronizePeerBinders:]
> ()
> #4 0x93b53ff0 in -[NSValueBinder
> releaseConnectionWithSynchronizePeerBinders:] ()
> #5 0x936bee00 in -[NSObject(_NSBindingAdaptorAccess)
> _releaseBindingAdaptor] ()
> #6 0x936bead8 in __NSViewDeallocAuxiliary ()
> #7 0x936bdedc in -[NSView _finalize] ()
> #8 0x936bdbe8 in -[NSView dealloc] ()
> #9 0x9372eb78 in -[NSControl dealloc] ()
> #10 0x9399f1cc in -[NSColorWell dealloc] ()
> #11 0x9369cad4 in -[NSView release] ()
> #12 0x928f1138 in __NSFireDelayedPerform ()
> #13 0x90770aec in __CFRunLoopDoTimer ()
> #14 0x9075d464 in __CFRunLoopRun ()
> #15 0x9075ca18 in CFRunLoopRunSpecific ()
> #16 0x9318e1e0 in RunCurrentEventLoopInMode ()
> #17 0x9318d7ec in ReceiveNextEventCommon ()
> #18 0x9318d6e0 in BlockUntilNextEventMatchingListInMode ()
> #19 0x9368c104 in _DPSNextEvent ()
> #20 0x9368bdc8 in -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #21 0x9368830c in -[NSApplication run] ()
> #22 0x93778e68 in NSApplicationMain ()
> #23 0x00012fa8 in main (argc=1, argv=0xbffffb28) at
> /Users/justin/Boom/main.m:13
>
> What I don't understand is why another one of my apps, which uses
> the same
> scheme of binding to the bgColor attribute of an outlet of the
> document
> class, fails to crash under the same circumstances. Is this app
just
> unluckily dealloc-ing myView first, then the color well? How is
> this sort
> of thing prevented in the common case?
>
> Thanks for any help,
> Justin
>
>
> --
> Studying texts and stiff meditation can make you lose your Original
> Mind.
> A solitary tune by a fisherman, though, can be an invaluable
treasure.
> Dusk rain on the river, the moon peeking in and out of the clouds;
> Elegant beyond words, he chants his songs night after night.
> -- Ikkyu, "The Fisherman"
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> 40bigpond.net.au
>
> This email sent to email@hidden
--
Studying texts and stiff meditation can make you lose your Original
Mind.
A solitary tune by a fisherman, though, can be an invaluable treasure.
Dusk rain on the river, the moon peeking in and out of the clouds;
Elegant beyond words, he chants his songs night after night.
-- Ikkyu, "The Fisherman"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden