It's because of wxFlatNotebook. It makes its notebooks accept drag'n'drop, effectively killing our drag'n'drop implementation...
This wx Drag and Drop problem puts CB between a rock and hard place.
In order to use wxFlatNotebook, it has to give up file DragAndDrop.
The very first SetDropTarget() that wxFNB uses deletes/frees the previous users (CB's)
DropTarget and sends it off to code nervana.
Its a wxWidgets thing. Wx doesn't chain or allow multiple drop targets in
the same window/frame. That leaves the last guy who used SetDropTarget() to
not only support his own drop format, but all those used previous to him.
Not good..
There is a way around this I think. Since wxFNB is using wxMouseEvents to
drive DragAndDrop, CB could use the same. With a few coding guidelines the
two could "chain" SetDropTarget() via mouse events and event.Skip().
Guidelines would be as follows:
Use your choice of mouse event to drive DragAndDrop
If the drop area isn't yours, pass it on with event.Skip()
Dont assume your drop target exists just because it was previous allocated,
allocate it anew each entry.
Set up data for your DragAndDrop formats
SetDropTarget to your window/frame
Execute the DoDragDrop
Pass on the event anyway with event.Skip()
Return;
A rough example would be:
myOnMouseMove(event wxMouseEvent)
If (not (HitTest()==my area of interest)) {event.Skip; return; }
// dont assume DropTarget still exists
myWindow* thisEvent = (myWindow*)event.GetEventObject();
if (myWindow.GetDropTarget() == 0) m_pMyDropTarget = new myDropTargetClass(thisEvent....)
wxDragInfo draginfo(this, ...);
wxDataObject dataobject(...);
dataobject.SetData(sizeof(dragInfo), &draginfo);
wxDropSource dragSource(this);
dragSource.SetData(dataobject);
SetDropTarget(m_pMyDropTarget);
dragSource.DoDragDrop(...);
event.Skip()
return
If you'd like, I could take a stab at patching and testing this idea.
thanks
pecan