ObjCJava WARNING:
old -initWithCoder: failed because ObjC result != self
is generated when running a Cocoa-Java version of the
NSDocument-based MathPaper example in Garfinkel & Mahoney's "Building
Cocoa Applications"; in particular, when restoring an archived file
in what I believe to be the correct fashion, even though the data
stored in the file HAS been successfully and correctly read. And I'm
wondering what I'm doing wrong...
--- The details ...
I've been creating first the Cocoa version described in "Building
Cocoa Applications", then an equivalent Cocoa-Java version.
Chapter 13 adds saving a simple NSDocument to a file, then reloading
it. The/my "pure Cocoa" version works fine.
My Cocoa-Java version invokes
NSKeyedArchiver.archivedDataWithRootObject(this) in the
dataRepresentationOfType( String aType )
method of my subclass MathDocument of NSDocument to save the state of
the MathDocument instance to a file. In the pure-cocoa version,
selecting the File - Open... menu item invokes MathDocument's
loadDataRepresentation(...) method, which invokes
unarchiveObjectWithData(...), which invokes initWithCoder(...), which
initializes the new MathDocument instance just fine, thank you.
In my Cocoa-Java version, MathDocument has a loadDataRepresentation(
NSData data, String aType ) method that invokes
NSKeyedUnarchiver.unarchiveObjectWithData( data )
but loadDataRepresentation(...) is not called when File - Open... is
selected. Instead, the constructor
public MathDocument( String fileName, String fileType )
is called. OK, so I copy the code in loadDataRepresentation(...) to
the constructor so that the body of the constructor invokes
unarchiveObjectWithData(...). MathDocument( decoder, token ) gets
invoked (as the Cocoa-Java documentation for the NSCoding interface
says will happen), and returns, but unarchiveObjectWithData(...)
prints out the above-mentioned warning, then throws an
"OBJCJava_RUNTIME_EXCEPTION".
**** and returns null instead of a reference for the MathDocument it
has constructed.
Now, the MathDocument(decoder,token) invocation HAS successfully
constructed the two instance variables in question (an NSFrame and an
NSMutableAttributedString); if I stash these in private static class
variables, then copy them into the corresponding instance variables
after ignoring the exception that unarchiveObjectWithData(...)
returns (instead of trying to initialize them from the MathDocument
instance that's supposed to be returned by
unarchiveObjectWithData(...), a fully-functional new window is
created with the correct frame and contents.
I realize Apple has officially declared that the Cocoa-Java bridge
will not be augmented to implemented any new-from-now-on features of
the Cocoa libraries, but this archiving stuff has been around for
quite a while. Seems like it should work. So ... likely I'm doing
something wrong. But I sure can't figure out what. If anyone's got a
suggestion, I'd be most grateful...
Note that in both versions, the File - Open... menu item is bound to
FirstResponder.openDocument, just the way IB set it up - I haven't
messed with it.
And BTW, I'm also curious as to what the purpose of the "token" parameter in
protected ClassName( NSCoder decoder, long token );
is - the aforementioned page is entirely silent...
Thanks a bunch.
--
------------------------------
Prof. John C. Beatty
School of Computer Science
University of Waterloo
200 University Avenue
Waterloo, Ontario
Canada N2L 3G1
+1 (519) 888-4567 x 4525 voice
+1 (519) 885-1208 fax
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
