Re: TextView and attachments
Re: TextView and attachments
- Subject: Re: TextView and attachments
- From: Renaud Boisjoly <email@hidden>
- Date: Tue, 2 Jul 2002 14:13:56 -0400
But certainly, when one pastes or drags a file _into_ a textView, it is
stored somewhere... and must be available and not just as a screen
representation...
I used to recreate the image by Copying the data into a hidden window
and creating an NSImage from the RTFD selection (a bit like a screenshot
if you like). This worked but seems really backwards and had some
issues...
There must be something to be done to allow Copy and Paste and Drag and
Drog from the textView when the document is not saved... this seems like
a required thing...
And all this works between two Cocoa apps, probably because the two
Cocoa apps support PDF which is placed on the Pasteboard
automatically... but the routines to do this must take the data
somewhere?
oh boy...
Renaud
On Tuesday, July 2, 2002, at 01:20 PM, Kirk Kerekes wrote:
On Tuesday, July 2, 2002, at 10:15 AM, cocoa-dev-
email@hidden wrote:
All I want is for my app to be able to drag an image even if a document
was not saved before... but even TextEdit doesn't do this...
Any ideas on what I should be looking into to master this concept?
AFAIK:
The core issue is that the NSFileContentsPboardType does not work as
advertised, at least in all circumstances. This may largely be due to
Carbon's inability to accept a drag for a file that doesn't exist on
disk -- a shortcoming that appears to still exist, despite much
developer ranting.
If you examine the TextEdit source code, you will find that when you
drag a file object _out_ of a text-edit document, the code passes not a
filewrapper, but a path to the file inside the RTFD document package.
The DraggingDestination then does what it wants with that path. In the
case of a drag-to-the-Finder, the Finder simply copies the file to the
destination.
You can't implement it "right", because the X "Finder" simply won't
accept drags for a file that does not yet exist. Who knows, maybe in
Jaguar.
This is why I just recently had to change my current doc-app project
from using an archived flat-file format with embedded RTFD streams to
using a multi-level package-file format where the document package
contains multiple RTFD packages with added archives for
application-specific data.
Thanks to the wonderfulness of Cocoa, this only took about a day. But
it really ought not to have been required. Interestingly, Cocoa made it
easy to implement the new format without discarding the old -- my app
can save or read either version with equal ease.
As my app is designed to automagically save documents without user
intervention, the document-must-be-saved issue is sidestepped. For a
conventional doc-app, I suggest saving a temp-file somewhere, although
I have read in postings on one of the Cocoa lists that the X-"Finder"
objects to using such files in the invisible system temporary-items
folder.
_______________________________________________
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.
_______________________________________________
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.