Hi all,

I’m updating some legacy code that currently uses the ‘classic’ way to drag stuff, namely

[NSView dragImage:at:offset:event:pasteboard:source:slideBack:];

This code has been deprecated forever (10.7+ anyway), so it’s about time it was updated to the modern dragging session API. However, the old code still works perfectly and has served faithfully for years.

The dragging session is created OK, and the dragging image drags as a semi-transparent image, so the drag is taking place alright. I can also see that the dragging destination methods are called as they should be.

The problem is that the source view needs to update while the drag is going on. The view is actually a stack of subviews, and the thing being dragged is one of them, to re-arrange the order of the views. So the first thing is that the view being dragged is hidden. This opens up a gap in the stack. As the drag proceeds, the remaining views animate their position to open up a gap where the view can be dropped.

In the old code, works great.

In the new code, nothing I do allows the view’s visual appearance to be updated during the drag. The view being dragged doesn’t hide (its ‘hidden’ state becomes YES, but it still shows), and the animation doesn’t happen, though once again the code that handles that is being called as expected. That calls -setAnimatedFrame: to reposition the other views to make space, but though its being called with sensible values, nothing actually gets drawn or redrawn.

It’s as if the run loop is suspended during the dragging session, so window updates are not processed. I’m not sure what to check to verify that guess.

SUrely normal updates should be allowed during a drag? How can the old code (that freely handles updates) be replaced if the new one doesn’t work the same way?

Anyone run into this problem, or knows what I should do here?

—Graham