Re: promising files in drags

• Subject: Re: promising files in drags
• From: Bryan Prusha <email@hidden>
• Date: Fri, 29 Jul 2005 13:20:49 -0700
• Delivered-to: email@hidden
• Delivered-to: email@hidden

On Jul 29, 2005, at 12:34 PM, Steve Mills wrote:

On Jul 29, 2005, at 13:49, Bryan Prusha wrote:

Drag file "promises" (an unfortunately overridden word) are still a little overly complex. I have ideas to address this in a future release but some of the issues involved are... subtle. =) Here's a link to documentation that should help you with understanding the current model.

http://developer.apple.com/technotes/tn/tn1085.html

Thanks. I read it and am still confused.

Understandable. =/

You need to set the DropLocation so the sending application knows where to place the newly minted file. Then you can call in their promise to kDragFlavorTypeHFS to the the real file data.

In this case, their app is responsible for the location of the file. Their app has a database of images. When they drag one to our app, they'll be responsible for creating an actual file on the server from the data in their db. A reference to this file will be given to our app in the drag receiver. So do we still need to call SetDropLocation, but with an empty file or an AEDesc of typeNull or some such thing?

The flavorDataPromised flag is set automatically by the system when a flavor is promised with NULL data. Requesting both flavor types are in the proper order is required for the full "promised file" handshake to be complete. This is why things are a little complex. Take a look at the documentation I provided above for more details.

So our tracking handler should look for kDragFlavorTypePromiseHFS first. If that's not found, we'll look for kDragFlavorTypeHFS like before.

Then in our receive handler, we should ask for the kDragFlavorTypePromiseHFS data (store it in a PromiseHFSFlavor), then ask for a flavor of type promise.promisedFlavor, and that will cause them to fill in an actual file reference that we'll then get?

• Prev by Date: Re: Optimizing a CFStringRef for CFStringCompare usage
• Next by Date: [OT] Future of CW - today's announcement at AdHoc
• Previous by thread: Re: promising files in drags
• Next by thread: What's faster: RGBA8 or ARGB8?
• Index(es):
  • Date
  • Thread