A .cbp file can be dragged to the "Opened Files" frame and the
"Management" banner.
But I cannot drag any files to the Management frame.
Is this by design or a bug. If a bug, could you point my nose to the code section and I'll see if I can glom a fix. It's probably just a case of copying a bit of code.
thanks
pecan
Edit: Win XP sp2; SVN 2016
It's because of wxFlatNotebook. It makes its notebooks accept drag'n'drop, effectively killing our drag'n'drop implementation...
Quote from: mandrav on February 16, 2006, 05:53:51 PM
It's because of wxFlatNotebook. It makes its notebooks accept drag'n'drop, effectively killing our drag'n'drop implementation...
Don't know if it matters, but eranif updated the wxFNB code in CVS a few days ago. You may want to check it out...... :)
Quote from: sethjackson on February 16, 2006, 05:57:27 PM
Don't know if it matters, but eranif updated the wxFNB code in CVS a few days ago. You may want to check it out...... :)
This has nothing to do with the actual version. It's a conflict. wxFNB uses its own drag'n'drop handler to allow dragging pages (even between different notebooks). So, if you drag any file over a wxFNB, wxFNB's drag'n'drop code is called instead of C::B's.
Clear now?
Yep. :oops:
Quote from: mandrav on February 16, 2006, 05:53:51 PM
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
QuoteIf you'd like, I could take a stab at patching and testing this idea.
Be my guest :)
The other solution is to remove drag'n'drop support from wxFNB...
Pecan: That would be great.
Do you have any idea if it's possible doing the same but for wxScintilla?
Quote from: Takeshi Miya on February 17, 2006, 03:10:02 PM
Pecan: That would be great.
Do you have any idea if it's possible doing the same but for wxScintilla?
Thanks for the reminder. I'll take a look at that...
thanks
pecan
Quote from: mandrav on February 16, 2006, 05:53:51 PM
It's because of wxFlatNotebook. It makes its notebooks accept drag'n'drop, effectively killing our drag'n'drop implementation...
February 18, 2006 8:21 AM
The code gnomes are yet bent-in-half laughing at me...
My idea to use mouse events to implement SetDropTarget() will not work when the drop source originates outside of the CB main frame because the operating system hides the mouse interrupts (events) until after the mouse key is lifted.
But (there's always a big butt...) that doesn't stop us from fixing the problem.
While inserting my favorite asm("int3") in the wxFNB code I realized that, at least for CB, wxFNB is not using its "wxFlatNotebook::DropTarget"; its using a "wxPageContainer::DropTarget" to drag tabs around.
So the simplest solution is to steal back the "main::DropTarget"
after instantiating wxFlatNnotebooks. So at main.cpp line 549 insert the following:
// wxFlatNotebooks are allocated by the Manager::Get() calls above. //pecan 2/18/2006
// wxFlatNotebooks isn't using the wxFlatNnotebook drop target for //pecan 2/18/2006
// CodeBlocks even though it sets them. It uses the wxPageContainer //pecan 2/18/2006
// drop target to drag tabs around. So here we steal back our Drag'n'Drop //pecan 2/18/2006
// targets in order to drop files into the project and files manager. //pecan 2/18/2006
m_pEdMan->GetNotebook()->SetDropTarget(new wxMyFileDropTarget(this)); //pecan 2/18/2006
m_pPrjMan->GetNotebook()->SetDropTarget(new wxMyFileDropTarget(this)); //pecan 2/18/2006
m_pMsgMan->GetNotebook()->SetDropTarget(new wxMyFileDropTarget(this)); //pecan 2/18/2006
patch has been submitted
thanks
pecan
2032
Quotefrom: mandrav on February 16, 2006, 11:53:51 AM
It's because of wxFlatNotebook. It makes its notebooks accept drag'n'drop, effectively killing our drag'n'drop implementation...
I believe I've gotten to the bottom of the "
wxFNB stole the drop target" problem.
The wxFNB constructor is issuing SetDropTarget(...) implicitly using its parents' window. It should be issuing "this->SetDropTarget(...)".
But... can it use "this->" in its
constructor?
If not, it should issue SetDropTarget(
this) outside of its constructor to avoid the theft.
This also means wxFNB's wxPageContainer:: is issuing SetDropTarget() on wxFlatNotebook instead of itself.
wxFlatNotebook::wxFlatNotebook(wxWindow* parent, wxWindowID id, const wxPoint& pos, const wxSize& size, long style, const wxString& name)
{
...code removed for brevity...
m_pDropTarget = new wxFNBDropTarget<wxFlatNotebook>(this, &wxFlatNotebook::OnDropTarget);
SetDropTarget(m_pDropTarget);
}
thanks
pecan
SetDropTarget(this) is allowed, because SetDropTarget takes a wxEvtHandler, and wxEvtHandler has already been initialised before wxFlatNotebook::wxFlatNotebook executes.
Quote from: thomas on February 28, 2006, 01:37:35 AM
SetDropTarget(this) is allowed, because SetDropTarget takes a wxEvtHandler, and wxEvtHandler has already been initialised before wxFlatNotebook::wxFlatNotebook executes.
I don't understand.
SetDropTarget() takes a wxDropTarget as an
argument and is issued via a wxWindow->SetDropTarget(...)
My question was about the constructor using its own "this" pointer:
i.e., is "this" pointer actually initialized in the constructor?
Will "this->SetDropTarget(wxDropTarget..)" be allowed in the
wxFlatNotebook constructor which _is_ ,in fact, executing at the point
that the SetDropTarget() is issued.
thanks
pecan
this->AnyDataOrMemberOfBaseClass good
this->AnyDataOrMemberOfCurrentClass good
this->AnyVirtualMemberOfCurrentClass evil
this->AnythingDerived evil
SetDropTarget is a member of a base class.
Quote from: thomas on February 28, 2006, 02:23:17 AM
this->AnyDataOrMemberOfBaseClass good
SetDropTarget is a member of a base class.
Ok, thanks. I'll give it a test.
pecan
Quote from: Pecan on February 28, 2006, 01:15:38 AM
I believe I've gotten to the bottom of the "wxFNB stole the drop target" problem.
Well... it seems I'm all wet, full of smoke, all bulls..t
Tracing through the wxFlatNotebook::SetDropTarget() call shows that
wxFNB is working fine. It uses its own window pointer; and the call destroys
no other drop target.
I'm stumped as to how the main.cpp drop target is being trumped by
wxFNB's SetDropTarget() call. But it is!
thanks
pecan
Is it the case that a wxPanel client area trumps (overrides)
a wxFrame client area when wxWidgets has to chose a
focus for an operation such as dragNdrop??
Is this why wxFNB (a wxPanel) can steal a DropTarget
from main.cpp's mainFrame (a wxFrame)?
thanks
pecan