<p>I'm implementing my app as a drag source. When I call DoDragDrop (Win32 call, not MFC) it enters into a modal loop and I don't get repaint messages in my main window until DoDragDrop returns. Unfortunately if I do a drop in the shell (a file) and the filename is already there the shell asks if I want to replace the file. But since me app is blocked because DoDragDrop  hasn't returned it isn't repainting and looks 'frozen'. </p>

<p>Any clues ?</p>

I suggest running the drag-and-drop operation on a different thread.  That way, DoDragDrop() will block the message loop in the new thread rather than the message loop in your UI thread.  If you take this approach, you should also consider (off the top of my head):
Any code that might be run from both your main thread and your drag-and-drop thread will need to be re-entrant.  As a corollary, you will need to protect any data structures used by both your main thread and your drag-and-drop thread.  If your application is already multi-threaded, you should be familiar with these concerns.
You should think about what happens if your user never responds to the shell's dialog box.  Can he continue to interact with your UI?  Can he invalidate the data that would have been 'dropped' in the pending operation?  Can he quit your application?