I found out what I did wrong. When dragging, you can have multiple items selected, and you can pick among them. I wanted the first one, so I called GetFlavorData (more about flavors later) with an index of 0. However it turned out that the first item is represented by 1.

Flavors show the data types contained in the dragged item. There can be more than one flavor. For example, when dragging a picture clipping from the desktop there can be a 'PICT' flavor for the contents of the data, and an 'hfs ' flavor for the file spec of the clipping file. I'm planning to use this feature within my application, since I can have the icons that is being dragged have a flavor type of it's resource type (ie 'icl8' so I can tell when depth and size it is, and if it's to be dropped on the mask container I can generate the mask instead of simply inserting the picture) and a 'PICT' flavor if the user is trying to export it to another program.

The next step was to add drop handling for all the regions in the editor (right now the only region being handled was the main drawing area, but things can be dropped onto the icon and mask displays to the right too). This resulted in a rather messy piece of code, since I had 3 collections of similar if statements, to determine over which area the mouse was (one for determining if it was a valid one, one for the drawing of the hilight rectangle, and one for determining over which area it was dropped). I'm sure it can be simplified, but I want to get it working first.

Then I ran into a weird problem. When dropping a picture onto the drawing area, a selection was supposed to be created, which contained the image data that was just dropped. This was drawn OK, but when attempting to move the selection, cut it, or choose another tool, there were drawing problems. After selectively commenting out pieces of code it turned out that this was caused by installing the drag handler procedures. Reading the docs carefully, it was mentioned that within those procedures the current port was set to the parent window, but no mention was made of it being restored when the procedure exited. Apparently the port was not being restored. To fix this I thought I should add a startupPort field to the class, so that I could explicitly call that at the end of the procedure. Since the startup port would be the same for all class instances, I thought I should make it static, so that it would be shared by all of them and not waste memory. However I ran into implementation problems. It turned out that simply declaring the static field in the class does not allocate it, you must do that by hand. But CodeWarrior reported this as a link error, saying the variable was undefined when I tried to access. I wasted half an hour tracking this down, since my C++ book, Practical C++ made no mention of this...