Re: How to update preview in NSPrintPanel?
Re: How to update preview in NSPrintPanel?
- Subject: Re: How to update preview in NSPrintPanel?
- From: Quincey Morris <email@hidden>
- Date: Wed, 28 Dec 2011 10:59:40 -0800
On Dec 28, 2011, at 05:05 , Luc Van Bogaert wrote:
> I haven't been able to set the checkbox's state to ON, when opening the print panel. I've tried creating the view controller first and then sending [viewcontroller setCheckBoxValue:YES], but that doesn't seem to work, so I suspect I'm still missing some important stuff (I assume point 3 and following..)
Parts 3-5 are the machinery that transfers the value from the printSettings dictionary to the view controller property. This is only necessary if you have code that sets the dictionary value directly; if you only use the initial dictionary value (i.e. the value at the time the checkbox is loaded from its nib) and/or only use 'setCheckboxValue' in the the view controller, you shouldn't need 3-5.
So, I'm guessing that the above problem is a small timing issue about when things happen. The first step would be to check each individual step of setting the initial YES. (I'd use the debugger, but you can NSLog instead if you prefer.) Check that view controller really isn't nil. In the setter, check that representedObject and printSettings really aren't nil. After returning from the setter, check immediately that the getter returns the value you just set. Etc.
> These are my current accessor methods:
>
> - (BOOL)checkBoxValue
> {
> return [[[[self representedObject] printSettings] valueForKey:kCheckBoxValue] boolValue];
> }
>
> - (void)setCheckBoxValue:(BOOL)checkBoxValue
> {
> [[[self representedObject] printSettings] setValue:[NSNumber numberWithBool:checkBoxValue]
> forKey:kCheckBoxValue];
> }
>
>
> ** Point 3: why exactly would this be required?
As I said already, you may not need 3-5 after all, but for completeness:
> I assume I could add this in -awakefromnib:
>
> [self addObserver:self
> forKeyPath:@"representedObject.printSettings"
> options:NSKeyValueObservingOptionOld | NSKeyValueObservingOptionNew
> context:self];
>
> and implement this in the view controller :
>
> - (void)observeValueForKeyPath:(NSString *)keyPath
> ofObject:(id)object
> change:(NSDictionary *)change
> context:(void *)context
> {
> if ([keyPath isEqualToString:@"representedObject.printSettings"]) {
> NSLog(@"%@", @"the printSettings object has changed");
I meant "keep track of" in the sense of "store in an ivar", so:
currentPrintSettings = [[[[self representedObject] printSettings];
> }
> }
>
> But, I'm not sure where to remove 'self' as an observer. I'm doubting that -dealloc is the right place for thisn but for now I have implemented it there:
>
> [self removeObserver:self
> forKeyPath:@"representedObject.printSettings"];
>
This seems like the right place to do it.
>
>
> ** Point 4: this is even getting a little harder for me…
>
Adding the next piece, the above becomes:
if ([keyPath isEqualToString:@"representedObject.printSettings"] && currentPrintSettings != [[self representedObject] printSettings]) {
[currentPrintSettings removeObserver: self forKeyPath: kCheckboxValue];
currentPrintSettings = [[self representedObject] printSettings];
[currentPrintSettings addObserver: self forKeyPath: kCheckBoxValue options: 0 context: self];
}
> Where should I remove "self" as an observer for the "first" print settings object? Also in -dealloc ?
Yup, but you're removing the observer from 'currentPrintSettings'.
>
> ** Point 5: now I'm definitely loosing track ;-)
Adding the last piece:
} else if ([keyPath isEqualToString:kCheckBoxValue]) {
[self setCheckBoxValue: [self checkBoxValue]]; // the point being to trigger a KVO notification of the view's property
}
and changing the setter to short-circuit the loop:
- (void)setCheckBoxValue:(BOOL)checkBoxValue
{
if (!checkBoxValue != ![self checkBoxValue])) // (the right way to compare 2 BOOLs)
[[[self representedObject] printSettings] setValue:[NSNumber numberWithBool:checkBoxValue]
forKey:kCheckBoxValue];
}
(Code written in mail, so I may have overlooked some details.)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden