Re: New Tiger NSDocument API's
Re: New Tiger NSDocument API's
- Subject: Re: New Tiger NSDocument API's
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 13 Jun 2005 11:12:37 -0700
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
_______________________________________________
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