[Dalgo]

I am writing a program in which I'd like the user to have the ability to arbitrarily choose the color of some interface items and I'd like it to save the color which the user chose to it's preferences. Unfortunately, I seem to have run into a few problems. You see, because of all of that colorspace nonsense I can't think of a good way in which to save the color. I know that NSColor has methods that will return the RGB value for a color or the CMYK value for the color but I can't get an RGB value for a color if they chose the color from the CMYK picker. I would really prefer it if I were able to save the color in one format as opposed to having all sorts of extra code working around all of this colorspace garbage.

So, does anyone know a way that I could save the entire NSColor object and simply reload it when my program starts? I think that saving and reloading objects at a program's launch would be a very useful thing to do. If no one knows how to do that, does anyone know when the colorUsingColorSpaceName: method will fail. In the header it says that it will return nil if it can't perform the required conversion. Are they any color spaces which can't be converted to RGB?

[lindberg]

Yeah, colors can be complicated.

You can use the -colorUsingColorSpaceName: method to convert colors between colorspaces. Most colors should be convertable to RGB that way, though I think there are a few CMYK colors that are not representable in the RGB colorspace.

You could check the -colorSpaceName, and create strings based on that -- if it's RGB, make a string like "RGB 1.0 1.0 1.0", if it's CMYK, something like "CMYK 0.0 0.0 0.0 0.0", etc. This wouldn't work for pattern colors though :-)

Probably the only way to truly store a color under any circumstances is to archive off the color object itself, like you said. It won't be editable by a human directly in the preferences text files, but it'll work. Use [NSArchiver archivedDataWithRootObject:theColor] to create an NSData representation of the color, and store that in preferences (setObject:forKey: handles NSData objects just fine). Coming out, use -dataForKey: to get the NSData, then use [NSUnarchiver unarchiveObjectWithData:theData] to get the NSColor back.

[Dalgo]

Wow! I never looked at NSArchiver. Freeze-dried objects! This is so useful! I had always thought that there should be a way to save an object... but I never knew that there actually was a way to do just that. That's so cool!

[Dalgo]

Stupid double post.

[This message has been edited by Dalgo (edited 02-04-2001).]

[lindberg]

Yup. :-) Obviously this only works for objects that conform to the
NSCoding protocol (which does include virtually every Apple-provided
class it makes sense to archive).

Incidentally, this is how InterfaceBuilder works. When you're
using IB, you're actually editing the live objects. Upon a save,
it archives the entire object graph into the .nib file. When you
load the .nib at runtime, it's essentially just unarchiving all
the objects.

[gregomni]

Distributed objects too. Archiving and unarchiving is how "bycopy" objects are transferred between processes.