@JonB But that's the thing, at the end of dropEvent it seems like the drag-and-drop operators are not yet completed (things like removing rows and so on happen after we exit it).
So that's going to take some unspecified time t and we must set the timer to an interval that is guaranteed to be greater than t. If we guess too low, we run the risk of running the action on an inconsistent state, so we must guess high and that may introduce a bit of a delay.
Also, does timer use application-time, or wall time? If wall time, then we would not guarantee correctness because in principle the OS may interrupt the application after dropEvent exits but before drag-and-drop is over, and when we resume it the time hits and we run it on an inconsistent state.
Anyway, this is all pretty academic, I think in practice your solution would work well.