Author Topic: Management Window Drag & Drop  (Read 17775 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Management Window Drag & Drop
« on: February 16, 2006, 05:42:52 pm »
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

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Management Window Drag & Drop
« Reply #1 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...
Be patient!
This bug will be fixed soon...

sethjackson

  • Guest
Re: Management Window Drag & Drop
« Reply #2 on: February 16, 2006, 05:57:27 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......  :)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Management Window Drag & Drop
« Reply #3 on: February 16, 2006, 06:10:30 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?
Be patient!
This bug will be fixed soon...

sethjackson

  • Guest
Re: Management Window Drag & Drop
« Reply #4 on: February 16, 2006, 06:19:32 pm »
Yep.  :oops:

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Management Window Drag & Drop
« Reply #5 on: February 17, 2006, 02:57:37 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
« Last Edit: February 17, 2006, 03:02:37 pm by Pecan »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Management Window Drag & Drop
« Reply #6 on: February 17, 2006, 03:03:32 pm »
Quote
If 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...
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: Management Window Drag & Drop
« Reply #7 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?

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Management Window Drag & Drop
« Reply #8 on: February 17, 2006, 03:22:13 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

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Management Window Drag & Drop
« Reply #9 on: February 18, 2006, 07:30:03 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:

Code
    // 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
« Last Edit: February 18, 2006, 07:32:40 pm by Pecan »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Management Window Drag & Drop
« Reply #10 on: February 18, 2006, 08:06:43 pm »
2032
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Management Window Drag & Drop
« Reply #11 on: February 28, 2006, 01:15:38 am »
Quote
from: 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.

Code
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
« Last Edit: February 28, 2006, 01:58:15 am by Pecan »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Management Window Drag & Drop
« Reply #12 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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Management Window Drag & Drop
« Reply #13 on: February 28, 2006, 02:10:13 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
« Last Edit: February 28, 2006, 02:13:02 am by Pecan »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Management Window Drag & Drop
« Reply #14 on: February 28, 2006, 02:23:17 am »
this->AnyDataOrMemberOfBaseClass     good
this->AnyDataOrMemberOfCurrentClass  good
this->AnyVirtualMemberOfCurrentClass evil
this->AnythingDerived                evil

SetDropTarget is a member of a base class.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."