What I find strange is the issue hasn’t already been seen earlier, as dragging several items is probably common.
Anyway, another way to solve your issue (may not suit your situation, I don’t know) would be to package all rows in a single drag item (e.g. an array like this: {row0+chr(0)+row1+chr(0)+row2+chr(0)+row3} as the only item’s text).
Dragging and dropping the way I am doing it isn’t necessarily all that common. I don’t see that many apps that have drag and drop between two list boxes. Big Sur hasn’t been out that long and many of us haven’t had a chance to go through every bit of our apps yet.
Adding selected rows like you said may work but then it would take parsing that when you drop it down on the other side. A lot of work for something that should work but doesn’t. It’s clear it is a framework issue.
There are some weird drag and drop issues with BS. In one place of my app where I create the dragItem myself, BS insists on displaying a “2” in the top right hand corner of the drag item. I’m only putting one item into the DragItem. It doesn’t show this on Catalina or below.
I’m finding BS has lots of UI issues. Try expanding an Ope File Dialog.
1 Like
The question isn’t if it’s a bug or not. I just wanted to discuss some possible workarounds as Xojo isn’t going to fix your bug tomorrow.
Sure. I like that idea!
Jon - I’ve noticed some really strange cut/paste & drag/drop behaviours in Big Sur - nothing I’ve been able to pin down specifically but more like ‘huh, why isn’t that dropping in’ or ‘huh, where has my copied item gone’.
Not in Xojo - just general use of the OS.
Thanks. And I agree. There’s definitely some quirks in this new OS.
So this isn’t just a matter of creating your own DropItem and then using that to drag and drop. The fundamental underlying drag and drop framework is broken. The framework and OS don’t recognize DragItems that have been added with DragItem.AddItem. The AddItem is what seems to be broken.
If you have a single listbox item selected (as in Xojo’s example) and say Drag.Text = SelectedText or whatever, then it all works fine. It’s when you add items using the AddItem method that it doesn’t work. To examine this further I did the following:
1.) Modified Xojo’s example and added a MyDragItem as DragItem to the Window.
2.) In the DragRow event of the “original” listbox, I have the following code:
Function DragRow(drag As DragItem, row As Integer) Handles DragRow as Boolean
drag.Text = Me.List(row)
MyDragItem = New DragItem(Me,0,0,0,0,Nil)
Dim nRows, i As Integer
nRows=Me.ListCount-1
For i=0 To nRows
If Me.RowIsFolder(i) Then
Continue
End If
If Me.Selected(i) Then
MyDragItem.AddItem(0,0,0,0)
MyDragItem.Text=Me.List(i) //get text
End If
Next
MyDragItem.Drag
Return True //allow the drag
End Function
3.) In the other listbox in the example in the DropObject event I have the following code:
Sub DropObject(obj As DragItem, action As Integer) Handles DropObject
#Pragma unused action
Dim row As Integer = Me.RowFromXY(XMouse,YMouse)
If row = -1 Then
row = Me.LastIndex+1
End If
Dim n As Integer = 0
Dim InsertRow As Integer
Do
If MyDragItem.TextAvailable Then
InsertRow = row+n
Me.InsertRow(InsertRow+1,MyDragItem.Text)
n=n+1
End If
Loop Until Not MyDragItem.NextItem
For i As Integer = 0 To Me.ListCount-1
Me.Selected(i) = False
Next
End Sub
Now since I assigned Drag = Me.List(row) in step 2, the drag and drop functionality works just fine. The problem is with that statement you can’t have multiple rows selected in the ListBox. You can only drag one row at a time. Using the code after that in step two, multiple items are added to MyDragItem in each iteration of the loop if they are selected.
The problem is multiple items are NOT being added. When the DropObject event fires in step 3, the only DragItem that gets added to the listbox is the very last one. I can select every item in the first listbox. The only item that gets successfully added to the DragItem is the very last DragItem.
So the framework is definitely broken here and in a way you can’t really workaround. I suppose you could create an array of drag items. But maybe it is easier to just force my users to move one row at a time until this gets fixed.
OK. I’ve made the following changes. This works:
Function DragRow(drag As DragItem, row As Integer) Handles DragRow as Boolean
drag.Text = Me.List(row)
Dim nRows, i As Integer
nRows=Me.ListCount-1
For i=0 To nRows
If Me.RowIsFolder(i) Then
Continue
End If
If Me.Selected(i) Then
Dim d As New DragItem(Me,0,0,0,0,Nil)
d.Text = Me.list(i)
MyDragItem.AddRow d
End If
Next
Return True //allow the drag
End Function
And on the drop side…
Sub DropObject(obj As DragItem, action As Integer) Handles DropObject
#Pragma unused action
Dim row As Integer = Me.RowFromXY(XMouse,YMouse)
If row = -1 Then
row = Me.LastIndex+1
End If
Dim n As Integer = 0
Dim InsertRow As Integer
For Each d As DragItem In MyDragItem
If d.TextAvailable Then
InsertRow = row+n
Me.InsertRow(InsertRow+1,d.Text)
n=n+1
End If
Next
For i As Integer = 0 To Me.ListCount-1
Me.Selected(i) = False
Next
End Sub
Now since I am just moving text here, I could simply create a text array for the items but the DragItem has the ability to add pictures, etc. It’s just broken at the moment…
In this specific case, I agree with you (since you spotted AddItem is broken). However, it could have been a bug in your code even if it works in Windows and earlier Mac OS versions, so, for testing purposes, don’t assume a somewhere-working code is problem-free.
Here’s a real example that was on an earlier Mac OS system (I don’t remember which one; let’s say 10.11): at that time, Xojo still allowed calling UI items from threads. Unaware of the fact it’s something to avoid, I carelessly used open dialogs from threads. This worked in Mac OS and Windows just “fine”.
Then, one day, a new Mac OS appeared (around 10.11). I came back in debugging some of my apps which oddly hanged: I could see a unexpected all-white window appearing and freezing the app.
Turns out it was my Open dialog being called from a thread and that new OS version decided to enforce the fact it shouldn’t be done.
Should I blame Apple for having done that change and not letting me continuing using open dialogs in threads or is it just me who was unaware of the fact that showing open dialogs (UI) in threads must be avoided and had a bug in my code (which wasn’t an issue in Windows or earlier Mac OS versions because they didn’t enforce avoiding this bad practice)?
This taught me to never assume something breaking in a new OS means the OS has a new bug until I’ve proven it’s not a bug in the user’s code.
1 Like
I don’t really use Drag and Drop in the IDE. It’s in my app. See the Fedback Report please.
DropItem.AddItem is broken.
Maybe the Navigaton Pane is built using a ListBox ?
Are-you able to copy two Events (two entries from the Navigation Pane) ?
Or AddItem is used there ?
Sure, but what Greg was getting at is that if drag and drop in the IDE is behaving, we have a hint of where to start looking for problems.
Don’t know. Does the IDE use DragItem.AddItem?
Last I looked my feedback report was in Needs Review status. Has Xojo looked at this and run my two example apps?
Dragging controls from the library to the layout editor uses dragitem, so does that work for you?
And it would be really nice if you actually reviewed the code in the example apps.
Yes, Drag and Drop from the IDE works fine. But I doubt you use DragItem.AddItem because in the IDE you can only drag a single control at a time. Dragging a single control or object works as Xojo’s Drag and Drop example works. But nowhere in that example is the AddItem method used.
Please focus attention to the AddItem method.
Ok, how about this… does dragging in the Navigator work?
It’s the weekend, I’m answering you from my phone today. We’ll look at this next week.
I’m just trying to get some answers to things that we’ll need to know anyway.
1 Like