Re: Best way to bind an Inspector to iVars/Properties?
Re: Best way to bind an Inspector to iVars/Properties?
- Subject: Re: Best way to bind an Inspector to iVars/Properties?
- From: Corbin Dunn <email@hidden>
- Date: Fri, 07 Dec 2007 12:42:21 -0800
Howdy!
I think option 9 is the best:
9. Just use NSRect as the ivar.
Example code:
@interface MyController : NSObject {
NSRect test;
}
@property NSRect test;
@end
@implementation MyController
@synthesize test;
- (void)awakeFromNib {
[self addObserver:self forKeyPath:@"test"
options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
context:nil];
self.test = NSMakeRect(2, 3, 4, 2);
self.test = NSMakeRect(2, 1, 4, 2);
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context
{
NSLog(@"changed %@, %@", object, change);
}
@end
KVO will wrap them in NSValue's for you.
corbin
On Dec 7, 2007, at 8:53 AM, Gordon Apple wrote:
I'm currently wrestling with how to bind inspector components to
the
variables of an object. I'm also becoming a Talmudic scholar of the
Sketch
example, although my architecture is substantially different. (I
have to
actually understand it, not just use it.)
My Shape objects are not based on subclasses, but on a highly
variable
list of properties. Structs are currently stored as NSValues, which
made
for easy archiving until I started trying to use keyed archivers.
That and
other issues have brought up the following considerations. What is
the best
way to handle structs like NSRect, NSSize, NSPoint and be able to
bind my
inspector to them?
1. Store as an NSValue (like I started) and use custom property
accessors
to bind to the components.
2. Create my own NSObject-based classes for these structs
3. Create a proxy holder class for these structs (with accessors)
4. Store all components in my props dictionary as individual NSNumber
components
5. Store components in their own dictionary within my props
dictionary
6. Give up on structs in my props dictionary and use separate iVars
with
component accessors (i.e, the Sketch approach)
7. Something entirely different
8. Find a new career which pays better with shorter hours
Any thoughts or experiences?
_______________________________________________
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
_______________________________________________
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