Submitted by LeftEccoForIQ on 2025/01/03 04:46

While I am very happy with the recent changes WRT drag and drop behaviour, a slight niggle has remained:

Currently, when I drag a TLI from my main grid to a grid shown next to it in a pane, the main grid's view is not updated and the item shows in both places until I manually refresh the main grid to make the item disappear from there.

However, in the reverse direction, when I drag a TLI from the grid shown in the pane to the main grid, the view is updated automatically and the item appears only in the targeted main grid. Also, when dragging to another grid by hovering over its tab on the tab bar (the fix allowing dragging across the tab works nicely BTW), and dropping the item in the selected grid, after switching back to the original grid the view has also been updated, so the result is as intended here as well.

I hope you can reproduce / fix. Many thanks!

Oh, and a happy new year to you, Pierre!!

Comments

Pierre, just wanted to check whether you're considering addressing this. If not, I may be able to have Autohotkey refresh the main grid on release of left mouse button after dragging from main grid to grid pane.

A short update:

I noticed that the source grid is not updated only when I drag the item to become a child of a TLI that already has children (when the TLI is folded the moved item is 'secretly' added as a further child without unfolding the tree) and when the drag is from the main grid to a grid displayed in a pane. In the same constellation, dragging to a TLI that does not yet have children works as expected and updates the source grid. Please Let me know if you can't reproduce and I'll upload a screencast.

Cheers

Hi Left,

I was not able to reproduce it, a screencast would be nice. There is a grid setting that affects this: "Keep source field when dragging out or demoting TLI". You're sure this is set to Off for the source grid?

 

Been tinkering a bit. So far, it is clear that it does not happen for basic grids that don't have any rules etc. associated with them being the drag's source. I'll experiment some more to narrow down the particular aspect of the smarter grid that's behind it.

Figured it out:

The target grid of the drag and drop still had these two active Auto-Assign rules:

A:A_Action=0
A:A_Pending=0

For any grid that had either of these two fields as its grid source, this would result in the behavior shown in the screencast. Removing these rules from the target grid in the pane fixed the issue.

The rules had become obsolete anyway since you made drag and drop assignments more consistent in a recent update.

Cheers

Bug reports