Return to Dragging.rtf CVS log

Up to [NeXTSTEP 3.3 examples] / Examples / AppKit / Draw

Sample Programs from NeXSTEP 3.3

{\rtf0\ansi{\fonttbl\f0\fswiss Helvetica;\f1\fmodern Courier;\f2\fnil Times-Roman;\f3\fmodern Ohlfs;}
\paperw11340
\paperh8400
\margl120
\margr120
{\colortbl;\red0\green0\blue0;}
\pard\tx520\tx1060\tx1600\tx2120\tx2660\tx3200\tx3720\tx4260\tx4800\tx5320\f0\b0\i0\ulnone\fs48\fc1\cf1 Dragging stuff into Draw (file: 
\f1 gvDrag.m
\f0 )\

\fs24\fc0\cf0 \

\f2\fs28 This file is intended to handle things that are dragged into a Draw document (files and colors mostly).  There are a couple of things to keep in mind about the files case.  The first is whether the file being dragged in is being ``linked'' (via ObjectLinks).  The second is whether we are going to display the contents of the file or just the file's icon (or even just the little link button icon).\
\

\f0\fs36\fc1\cf1 Registering\

\f2\fs28\fc0\cf0 \
The basic idea is that we call 
\f1\b\fc1\cf1 registerForDragging
\f2\b0\fc0\cf0  in 
\f1\b\fc1\cf1 GraphicView
\f2\b0\fc0\cf0 's 
\f1\b\fc1\cf1 initFrame:
\f2\b0\fc0\cf0  and in 
\f1\fc1\cf1 awake
\f2\fc0\cf0 .  That calls the 
\f1\b\fc1\cf1 registerForDraggedTypes:count:
\f2\b0\fc0\cf0  method to let the system know which types of things (represented by 
\f1\b\fc1\cf1 Pasteboard
\f2\b0\fc0\cf0  types) we are interested in having dragged into our view.\
\

\f0\fs36\fc1\cf1 Reacting to a Dragging Session\

\f2\fs28\fc0\cf0 \
Next, we implement some of the dragging protocol as follows:\
\
1. 
\f1\b\fc1\cf1 draggingEntered:
\f2\b0\fc0\cf0 \
\
This is sent to us the first time something that we are interested in enters our view.  We respond by letting the system know whether we are actually interested in the dragged thing at the time the thing is dragged into our view (depending both on the state of our view and where the drag is) and what operations we will support.\
\
Basically, if the dragged thing is a color, we return that we will perform the ``generic'' thing on that color if dropped only if the 
\f1\b\fc1\cf1 Graphic
\f2\b0\fc0\cf0  that is currently being dragged over can deal with having a color dropped on it (the 
\f1\b\fc1\cf1 acceptsColor:atPoint:
\f2\b0\fc0\cf0  method is what we have created to figure this out).\
\
Otherwise, we will accept the dragged thing if it is a file of any sort or if 
\f1\b\fc1\cf1 NXImage
\f2\b0\fc0\cf0  says that it can make some sense out of the 
\f1\b\fc1\cf1 Pasteboard
\f2\b0\fc0\cf0  of stuff being dragged in (this last case is very rare, applications rarely let you drag raw EPS out of themselves and into other apps--maybe more applications will start doing this in the future, we'll have to see).\
\
In reality, we shouldn't say that we can accept 
\b any
\b0  sort of file.  We can really only accept files that 
\f1\b\fc1\cf1 NXImage
\f2\b0\fc0\cf0  can handle, RTF files, and (most of the time) plain files (because their usually ASCII).  We can easily determine if a filename is one 
\f1\b\fc1\cf1 NXImage
\f2\b0\fc0\cf0  can handle (and we can obviously tell whether it's an RTF file), but the only way we can tell if a file is a ``plain'' file (i.e. not a WriteNow file or some such) is by asking the Workspace Manager (see the message we send to 
\f1\b\fc1\cf1 [Application workspace]
\f2\b0\fc0\cf0  below).  Unfortunately, since the drag protocol is a synchronous blocking protocol between the app and the Workspace, we can't talk to Workspace in the middle of the drag (what a drag, huh?).\
\
So, what we do is just accept any file, and, if you drop a WriteNow file in (without linking, of course), then we just ignore it.\
\
Speaking of linking, if the link key (the Control key) is down during the drag, then we really can accept any file because we can just drop its icon into the Draw document (like Mail does).  Then we just use ObjectLinks to make the double-clicking on it open the file up.  We also provide the user the option of creating a little Link Button instead of the file's icon.\
\
2. 
\f1\b\fc1\cf1 draggingUpdated:
\f2\b0\fc0\cf0 \
\
This is called repeatedly as the dragged thing is dragged about our view.  Again, just like 
\f1\b\fc1\cf1 draggingEntered:
\f2\b0\fc0\cf0  we return whether we are interested in accepting the dragged thing depending on where it currently is in our view and our current state.  This method must be pretty fast, and it is, because we have already examined the contents of the 
\f1\b\fc1\cf1 Pasteboard
\f2\b0\fc0\cf0  in 
\f1\b\fc1\cf1 draggingEntered:
\f2\b0\fc0\cf0 .\
\
Basically all we really do of interest here is constantly reevaluate whether the 
\f1\b\fc1\cf1 Graphic
\f2\b0\fc0\cf0  underneath the dragging is willing to accept a color (but only, of course, if it is a color we are dragging).\
\
3. 
\f1\b\fc1\cf1 performDragOperation:
\f2\b0\fc0\cf0 \
\
This method is called just as the user lets go of the thing she's dragging.  This is normally where you do the work that the drop of the dragged thing causes.  And, indeed, if the dropped thing is a color, we update the color of the dropped-on 
\f1\b\fc1\cf1 Graphic
\f2\b0\fc0\cf0  here.\
\
Unfortunately, often dropping something on a Draw document causes two very time-consuming things to happen.  First, a complicated PostScript or TIFF image might have to be drawn.  Second, a question might need to be asked of the user about how to deal with the dropped thing (this happens when you link a file in and Draw wants to know whether you want the contents of the file to appear in Draw, the file's icon, or a link button).\
\
Thus, we don't do the work that the drop results in in this method, instead, we wait until after the drag and drop is fully complete (as far as the system is concerned) and do the work in ...\
\
4. 
\f1\b\fc1\cf1 concludeDragOperation:
\f2\b0\fc0\cf0 \
\
This is called after the drag and drop is completely done (and Workspace is out of the loop).  Thus, if there's an error, we can't do the ``slide-back'' animation.  It's a bummer, but there's really no way around it in 3.0.\
\
This method is implemented by first looping through any filenames that are in the dragged 
\f1\b\fc1\cf1 Pasteboard
\f2\b0\fc0\cf0  looking either for 
\f1\b\fc1\cf1 NXDataLink
\f2\b0\fc0\cf0  files (
\f1\b\fc1\cf1 .objlink
\f2\b0\fc0\cf0  files) which represent links (these are similar to the little things dropped in the filesystem in the Publish/Subscribe mechanism) or for files that 
\f1\b\fc1\cf1 NXImage
\f2\b0\fc0\cf0  can handle (TIFF, EPS, other formats if you have filters lying around), or for RTF or plain files that the 
\f1\fc1\cf1 Text
\f2\fc0\cf0  object can handle.\
\

\f1\b\fc1\cf1 createGraphicForDraggedLink:at:
\f2\b0\fc0\cf0  handles the 
\f1\b\fc1\cf1 .objlink
\f2\b0\fc0\cf0  files, and 
\f1\b\fc1\cf1 createGraphicForDraggedFile:withIcon:at:andLink:
\f2\b0\fc0\cf0  handles all other files.  
\f1\b\fc1\cf1 createGraphicForDraggedLink:at:
\f2\b0\fc0\cf0  is implemented simply by instantiating the link from the file and then calling the one method in all of Draw that actually adds a linked thing to the document (
\f1\b\fc1\cf1 addLink:toGraphic:at:update:
\f2\b0\fc0\cf0  -- see 
\f1\b\fc1\cf1 gvLinks.m
\f2\b0\fc0\cf0 ).  
\f1\b\fc1\cf1 createGraphicForDraggedFile:withIcon:at:andLink:
\f2\b0\fc0\cf0  also calls that same method if we are linking the dragged file in.  The method called when you do a Paste and Link from the menu also calls that method.\
\
Finally, if we can't find any files that we can do anything with, we just call the same method that is called when you hit Paste in the menu (except that we go straight to handling only non-Draw formats).  Nice code reuse, huh?  Again, this last thing is pretty rare (at least it is today, who knows what tomorrow will bring?).\
\
By the way, you may will ask what this 
\f1\b\fc1\cf1 ERROR
\f2\b0\fc0\cf0  thing is all about.  Well, the create functions return 
\f1\b\fc1\cf1 YES
\f2\b0\fc0\cf0  if they were able to successfully incorporate something into the document, 
\f1\b\fc1\cf1 NO
\f2\b0\fc0\cf0  if they weren't, and 
\f1\b\fc1\cf1 ERROR
\f2\b0\fc0\cf0  if they found a problem with the thing being incorporated (i.e. a PostScript error in a dragged EPS file, for example).\

}

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.