Thank you Stefan,
It was my previous idea (and it was working). I was trying to get the button to send its message directly to the object (bypassing the app controller). Sort of [myButton setTarget: self]. With your solution, one button (outside the tableView) will do it (of course, one line has to be selected first). Maybe this is a more orthodox solution. No “intra-object” message within button and status value.
My solution assumes that the button is within the table view as a button cell instead of a text cell
Works, within or outside the view.
One more thing: the dictionary has a handy method to save itself to a file. But (ah ah) it cannot save images or buttons. My record can. How? Using NSKeyedArchiever, for example? or: is it possible to save the whole NSArray containing the records using the same method?
I’m assuming you accidentally left out a “not” there, given that it’s inside an init method.
Actually I didn’t.
I’m aware that Apple recommends to avoid initializing instance variables through accessors in init methods,
but as long as you don’t subclass the class and override the accessor method there is no problem
to assign values to synthesized properties with self.ivar after self = [super init]
In most cases it’s useless to store instances of UI elements in user defaults.
To be able to store custom classes in user defaults, the class must adopt the NSCoding protocol and implement the required methods. In case of NSImage use the data representation instead of the NSImage instance
That’s a bit different from “must”, though…
Indeed, I apologize
No need to apologise; I just wanted to get it straight for lurkers.
Well. No way to save my controller’s array using this:
BOOL result = [NSKeyedArchiver archiveRootObject:[arrayController arrangedObjects]
toFile:archivePath];
I get:
2012-06-13 14:04:34.686 TestNewClasses[900:403] -[BFTestRecord encodeWithCoder:]: unrecognized selector sent to instance 0x7ff0ee4148d0
2012-06-13 14:04:34.688 TestNewClasses[900:403] -[BFTestRecord encodeWithCoder:]: unrecognized selector sent to instance 0x7ff0ee4148d0
2012-06-13 14:04:34.693 TestNewClasses[900:403] *** -[NSKeyedArchiver dealloc]: warning: NSKeyedArchiver deallocated without having had -finishEncoding called on it.
But I’ve used this NSKeyedArchiver before, without needing “finishEncoding”.
The class BFTestRecord must adopt the NSCoding protocol and implement at least the method encodeWithCoder:
Please read Archives and Serializations Programming Guide
Stefan,
You are going to find me monomaniac, but NSDictionaries have built-in coders. 
writeToFile: of NSDictionary/NSArray can also only write out property list compatible objects.
I know, but what do you thing of this:
-(IBAction)add:(id)sender {
long kount=[[arrayController arrangedObjects]count]+1;
NSMutableDictionary *theDic = [[NSMutableDictionary alloc]initWithObjectsAndKeys:
[NSString stringWithString:@“<>”],@“description”,
[NSNumber numberWithInt:kount],@“ID”,
[NSString stringWithFormat: @“New name for %d”,kount],@“name”,
[NSImage imageNamed: @“NSStatusNone”],@“statusImage”,
[NSNumber numberWithBool:NO],@“status”,
nil ];
[arrayController addObject:theDic];
}
.
-(IBAction)archive:(id)sender {
BOOL result = [NSKeyedArchiver archiveRootObject:[arrayController arrangedObjects]
toFile];
This stores images, as well as a textView with images. But of course not into a property list 
I’d save an enumerated value (for example 0 = none, 1 = invalid, 2 = valid) rather than a memory expensive image.
Is there a system image NSStatusNone? If not, it’s not recommended to use the reserved prefix NS.
And be careful with primitive types: long kount does not match numberWithInt:kount.
Actually the count message of NSArray returns an NSUInteger value (U = unsigned)
Of course you’re right, Stefan! For system images like NSStatusNone (a grey bubble which is not listed in Xcode, I don’t know why), I would use an enumerated value, or the name of the image. It was just a test: I knew that an archiver could save almost everything, including cocoa objects with their bindings, but it’s the first time I save a whole array of dictionaries full of keys, it’s incredibly fast and reliable.
I’m not abused by this little wonder, however. I know that people like you or DJ are right when it comes to more accurate or complex data, maybe large databases or custom views: in these cases, subclassing is certainly the only way to get the job done. I keep playing with subclassing, I just want to avoid subclassing something and discover ten hours later that I missed a cocoa feature which does the work better and faster.
you mean NSImageNameStatusUnavailable
No, I tried with NSImageNameStatusUnavailable and got nothing. But NSStatusUnavailable gets the bubble. I don’t know why. Same thing with “NSStatusAvailable” and “NSStatusPartiallyAvailable”.
From the docs:
You should really be using the constants rather than the strings…
Thank you for this distinction, Shane.
Is it possible to use such constants in IB? And how can I use these constants in code?
[NSImage imageNamed: NSImageNameStatusNone]
doesn’t work.