Drag and Drop problems in wxPython 4.1.0 on Windows

(I sent this to the list 2 days ago via e-mail, but I never saw it come through and it’s not posted on the Discuss board, so here it is again. Sorry if this a duplicate.)

I use python 3.7 and wxPython 4.1.0 on both Windows 10 and MacOS Catalina. I’m trying to get a large, complicated application working on Catalina, and some of what I do depends on wxPython 4.1.0 to work.

I have a bit of custom Drag-and-Drop behavior defined in my application, some of which have stopped working on Windows only since I upgraded to wxPython 4.1.0. This problem did not exist in the last 4.0.x daily build I was using.

In my wx.PyDropTarget, and in the DoodleDropTarget object in the CustomDragAndDrop demo in the demo files, the “OnData ()” method has parameters for x, y, and dragResult. The dragResult parameter should either be wx.DragCopy (a value of 2) or wx.DragMove (a value of 3), which is indeed what it contains in wxPython 4.1.0 on MacOS and in wxPython 4.0.x on Windows. However, in wxPython 4.1.0 on Windows, it instead contains a value of 1, regardless of whether the Drag-and-Drop operation was a Copy or a Move operation. Since I need to differentiate between a Move and a Copy, this is obviously a problem for me.

You can see the problem in the CustomDragAndDrop demo if you run it in parallel on Windows and MacOS. When you drop the image on the drop target, you can look in the log messages and will see that the OnData and DragDrop completed lines show a parameter value of 1 on Windows regardless of Move or Copy, while they show a 2 for Copy and 3 for Move on MacOS. Based on many past wxPython versions, MacOS is behaving correctly and Windows is not.


Very odd… I’m looking into this now.

Looks like it was a regression in wxWidgets that has been fixed as of a couple weeks ago.

I’ll update the wxWidgets reference we use so the fix will be in the next snapshot build.

Hi Robin,

  Thanks.  Would it be possible to get a daily build with that

fix? It’s been a couple of weeks since there was one, and this is
kind of a show-stopper for me at the moment.

  I also have a second issue that doesn't seem to have come through

to the list either. I’ll post that separately, as it doesn’t
belong in this thread. It’d be great if you could give that a
quick look when you have a chance.


Yes, ASAP. I had planned on committing the needed changes for last night’s build window, but I ran into a wxWidgets compilation error on Windows with the new code there. Once that is resolved then it should be good to go.

Hi Robin,

  Wonderful.  Thank you so much.  I really appreciate your


Stay safe.


Hi Robin,

  I installed the newest daily build,


I see the correct dragResult value

  I got the following error message when I tried to use my

drag-and-drop code:

<class ‘wx._core.wxAssertionError’>
C++ assertion ““Assert failure”” failed at
…\src\msw\ole\droptgt.cpp(705) in ConvertDragEffectToResult():
invalid value in ConvertDragEffectToResult
line 2740, in OnCutCopyBeginDrag
dragResult = tds.DoDragDrop(True)

  Traceback (most recent call last):

line 2740, in OnCutCopyBeginDrag
dragResult = tds.DoDragDrop(True)

  wx._core.wxAssertionError: C++ assertion ""Assert failure"" failed

at …\src\msw\ole\droptgt.cpp(705) in
ConvertDragEffectToResult(): invalid value in

(tds is a wx.DropSource object.)

Any ideas?


The ConvertDragEffectToResult function is only used in the drop target code, so this may not be the cause, but the DoDragDrop parameter is not a bool type. See https://wxpython.org/Phoenix/docs/html/wx.DropSource.html#wx.DropSource.DoDragDrop

If that’s not it, then look at the DropTarget.On* methods that you override and ensure that those which are to return a wx.DragResult enum value are doing so, and not returning something else.

I see what’s happening. Under certain circumstances, I wanted to
signal that the target did not accept the data, so I was changing
the dragResult to wx.DragNone. Apparently, this value is no
longer acceptable as the return value for a wx.PyDropTarget’s
OnData() method.

  Thanks for your help.  The new daily build means I can move

forward again.


I think the way to do that is to do it in OnDragOver, or to veto the drop you can return False from OnDrop.