Re: Simplifying this code?
Re: Simplifying this code?
- Subject: Re: Simplifying this code?
- From: "Theodore H. Smith" <email@hidden>
- Date: Tue, 27 Jul 2004 15:34:41 +0100
I find it all very confusing, to be honest. Dearchiving creates a new
object? What if I just want to restore values into an existing object?
Lets say I do this:
V *MyQuartzView; // Assume this exists.
result = [NSKeyedArchiver archiveRootObject:V
toFile:@"/tmp/FractalArchive"];
Now, will that work if MyQuartzView is defined like this?
@interface MyQuartzView : NSView {
IBOutlet NSColorWell *ColorWell;
IBOutlet NSTextField *CutField;
IBOutlet NSProgressIndicator *MyProgress; // this one I don't want
saved!
IBOutlet NSButton *TurnsSwitch;
....
MyRect* Rect;
}
Will it automatically store all IBOutlets? Or will it automatically
store everything including MyRect? In fact, if I had gone and used my
own archiver I could have done this already, because my design is much
simpler to explain. But I'm just trying to learn some Cocoa here :o)
On 27 Jul 2004, at 13:35, Mario Diana wrote:
On Tuesday, July 27, 2004, at 07:13 AM, Theodore H. Smith wrote:
Can I serialise the NSView subclass itself? My NSView has many text
fields, one custom serialisable object, and other controls.
Well, keeping with the model-view-controller pattern, the data
displayed in the GUI will not be kept in the GUI objects themselves,
but in the model. (In a really simple Cocoa application the model and
controller often are combined.) So, whatever object you use to
comprise the data that the NSView then displays, that's the object you
serialize. (Just an aside, Cocoa uses the term "archive" rather than
serialize. No big deal, but that's what you'll find in the
documentation.)
Classes that support archiving implement the NSCoding protocol. NSView
does implement it, but I don't believe that that will support
archiving of your data; I believe it only supports the actual GUI
design. For instance, if an NSView comprises other NSView objects,
sending the message to archive the top level object will in turn send
the same message to the sub objects. Again, that will only be the GUI,
not the data.
If I understand the above correctly, this is what the framework counts
on when it unpacks your Nib files.
Everyone does some non-OO coding at some point in their project.
Agreed. Often it is easier and as clear or even more clear to another
programmer than setting up a "proper" OOP design: "i = i + 1" rather
than some kind of iteration. But, I don't think that's the case here.
Aaron Hillegass's book has a great chapter on archiving. The Apple
documentation is here:
http://developer.apple.com/documentation/Cocoa/Conceptual/Archiving/
index.html#//apple_ref/doc/uid/10000047i
Mario
=======================================================
Mario Diana Mobile: 845-380-8428
50 Forest Drive Home: 845-221-3989
Poughquag, NY 12570 Email: email@hidden
=======================================================
Programmer - Web development, Java, XML, LAMP, Mac OS X
=======================================================
--
Theodore H. Smith - Software Developer.
http://www.elfdata.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.