This is only with Windows, and I create a Picture and add it to a DragItem, but Xojo always places at 0, 0 of the window, not where the Mouse is. The manual’s example shows creating a New DragItem, whereas in my use I’m using the one automatically generated by the DragRow event of a ListBox.
This works on Mac, the DragPicture shows where the mouse cursor is. But in Windows, the DragPicture displays at 0,0 of the parent Window. There’s nothing documented WHERE the DragPicture displays except in the Constructor, but DragRow creates the object, not me.
Even though the docs say that DropLeft and DropTop are read only, they aren’t (doc bug?), so if you use this it should put the image in the center of the mouse (you might need to adjust the offsets if you are in a container etc)
Still doesn’t work though. I actually didn’t list my DropTop and DropLeft assignments just because I read the docs and saw they were read-only. Regardless, I’m not interested where the DragPicture is when it drops (which is what the docs say - another mistype?), I’m interested in where it gets placed in relation to the mouse cursor upon the start of the drag and through the drag UNTIl it drops.
Thanks Julian. I tried the example on Windows and it doesn’t even start the drag. I tried it on Mac and it works great. Perhaps there’s an issue in that I am running Xojo 2019.1.1 on Windows 7 and Xojo 2019.3.2 on Mac (10.14). Trying to avoid upgrading to 3.2 on Windows, certainly there can’t be such a big bug in 1.1?
Check Enable Drag on both the list boxes (Allow Row Dragging was changed/added after 2019r1.1) then give it another try. Works fine here, image centered on the mouse. W7 2019r1.1
Thanks Julian, figured it out. I use a series of functions, and I add some more Items to the DragItem to do what I want.
I had some Kollection Konfusion; the DragItem uses a Items in a collection of sorts. I was calling AddItem on a DragItem that already had the Item “naturally added”. As a result, anything I set DropLeft/DropTop was being applied to the wrong Item within the DragItem. Strange that Mac didn’t have the same behavior, I’m guessing that there is some additional support where the programmer is “covered” if he makes a mistake like this.
Once I took out the unneeded AddItem, worked great. Thanks!