Re: New Tiger NSDocument API's
Re: New Tiger NSDocument API's
- Subject: Re: New Tiger NSDocument API's
- From: Philip Ershler <email@hidden>
- Date: Mon, 13 Jun 2005 13:13:25 -0600
On Jun 13, 2005, at 12:12 PM, Bill Bumgarner wrote:
On Jun 13, 2005, at 9:27 AM, Philip Ershler wrote:
On Jun 13, 2005, at 10:12 AM, Bill Bumgarner wrote:
On Jun 13, 2005, at 9:01 AM, Philip Ershler wrote:
The files I need to read (and ultimately write) are custom
format files that come from a data acquisition system that has
been designed and built in our institute. The files consist of a
1024 byte header followed by a stream of 16 bit integers. Total
files size may run from several hundred kilobytes to 1 or 2
gigabytes.
Given that the files will be the data spewed by the DAQ system,
it is unlikely that your application will need to write said
files? That is, the files containing the acquired data will be
treated more like something you import into your application and
less like a true document?
At this point, I'm just trying to open and display data from some
existing DAQ data files. Ultimately, I'm going to be writing an
application that streams data from the DAQ system (via a firewire
interface that I have designed) to disk. This application will
also need to be capable of opening and displaying existing files.
OK; Now I have a better understanding of the problem. It still
sounds like the DAQ files are read-only from the perspective of
your application.
That is, an individual document may contain configuration
information or, even, data that has been imported.
Indeed, each document will contain configuration information and
the acquired data.
Right.
Then, add an "import" menu item (or support drag and drop) such
that your app can import or accept the raw data files sourced
from the DAQ system.
I'm a bit confused about your "import" suggestion. The files in
question "belong" to this application. What I'm trying to do at
this point is just use "Open" from the File menu to open and
display a DAQ file.
Yeah -- import was the incorrect term. Re-thinking this slightly,
I would recommend that your application support TWO document
types. The first would be your DAQ file (they will need to have a
consistent extension) where your Application's role is declared to
be read-only.
That is, double-click the application target in Xcode (you'll find
it under "Targets" in the groups & files outline view -- if in
condensed mode, you may have to click the "Targets" tab) and click
on the "Properties" tab within the resulting inspector. There is
a "Document types:" table view within which you can create and
managed the document types.
You will want two; one that is for your DAQ files that is marked
as viewer only and one that is for your "session documents" that
will have a role as "editor".
For now, you can probably just focus on the viewer only DAQ files.
The template starts with...
- (BOOL)loadDataRepresentation:(NSData *)data ofType:(NSString *)aType
... overridden in the document class. That is fine for Panther.
If you are targeting Tiger only, you should swap the above with...
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
error:(NSError **)outError;
... which is now the correct way to do things.
The NSData that is passed in to that method will be the memory
mapped contents of your file. That is, if you try to open a 2GB
data file, it won't actually try to directly allocate and read 2GB
of data into memory. If you need a different style of I/O -- one
that does not use memory mapping of the entire file -- then you
would want to override...
- (BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)
typeName error:(NSError **)outError;
... on Tiger and the equivalent readFromFile: on Panther. You do
not want to use the File Wrapper based methods as those are
specifically designed to decouple the reading of the file from the
file's path as a part of the NSDocument architecture.
Now, since your application -- if you follow the above pattern --
will be READ ONLY for DAQ files and you won't need to worry about
the writing methods. When you do decide to write a document, then
you would switch on typeName in the above methods and also create a
write method that writes your document data.
b.bum
Thanks for everyone's input on this issue!
Phil
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden