How do I suppress full window drag/resize for just one window?

A customer asked,

Is there a way to turn off Full Window Drag on a single window? I have a resizable control that I would like not update itself while resizing.

It so happens that I wrote a sample program ages ago to illustrate how to do this. You can find it in the Platform SDK under winui\fulldrag. The source code is also reproduced in this Knowledge Base article.

In addition to deferring painting, you may also want to defer layout if layout is expensive for your window.

Comments (12)
  1. acq says:

    Cool. A small advice for anybody willing to try:

    To demonstrate the program on current computers the MAXDEPTH should be set to something bigger like 11. Then first modify Hilbert_OnPaint to have

       if (0 && g_fDragging) {

    recompile and observe how resizing behaves. Then change the line back to

       if (g_fDragging) {

    recompile again and observe the difference.

  2. Ben says:

    Nice! Hilbert curve, truly classy.

  3. Marquess says:

    For some reason, my first association for “Full Drag” has more to do with RuPaul than with Windows …

  4. Crescens2k says:


    I completely understand this. There have been pleanty of times I have read something and the first thing I thought of afterwards was "wrong".

    Hmm, the only issue with this kind of thing is that there would be WM_PAINT messages generated while you are dragging, even if you just not paint. So you will be using up processor time because of the paint messages. Well, it is better than painting every time (since that is a lot more expensive). But I’m sure there are people out there who would want a way to just switch it off with one call.

    (And just in case, I’m going to put a disclaimer on this. I am a supporter of Windows. The above is not saying I want a way to suspend this behaviour with one call or anything like that. I am happy with the way Windows does things, even if they are frustrating at times)

    But I am surprised, usually there are people bashing how the window manager works in cases like these. Where have they all gone today?

  5. Gabe says:

    Crescens2k, how many times do you think the mouse cursor can move every second? 10? 100? 1000? My guess is the answer is closer to 10, but I doubt you could get WM_PAINT messages more often than the screen refresh rate (about 100). It would probably have to be a million before you’d notice the extra WM_PAINT messages.

  6. Neil says:

    WM_PAINT "messages" get coalesced anyway.

    It’s fortunate that the customer clarified their question, since that made it much easier to answer. (A literal answer to their question would probably have involved messing around with SystemParametersInfo.)

    Things get trickier when you want to perform "near-live" update, that it, you want to be able to interrupt your layout process to handle the next mouse move. You can’t just post yourself a message to remind you that you haven’t finished layout, because the windowdrag event loop will simply process the posted message first.

  7. error says:

    error C2440: ‘=’ : cannot convert from ‘HGDIOBJ’ to ‘HBRUSH’

    error C2440: ‘=’ : cannot convert from ‘HGDIOBJ’ to ‘HPEN’

    warning C4101: ‘rc’ : unreferenced local variable

  8. redundant calls says:

    Is it necessary to call BeginPaint/EndPaint on every wm_paint, even when not painting anything?

    [Try it and see. -Raymond]
  9. Marquess says:


    Works fine with nmake and the current SDK here. What compiler are you using?

  10. redundant calls says:

    > [Try it and see. -Raymond]

    I did (years ago), appears to work. Still dont know what the window manager expects though.

    [I think you let the message pass through to DefWindowProc, which handles it by calling BeginPaint/EndPaint and painting just the background. That’s different from handling the message but never painting. (If you do that, the window manager just send you another paint saying “Try harder this time.”) -Raymond]
  11. @error:

    For the first two, just add two casts, they are legitimate because SelectObject returns a generic HGDIOBJ while the code stores the return value in variables of the exact type of the object.

    For the last one, it seems that that var has been forgotten from some previous version of that code. I assume you can remove it safely.

  12. Wilczek says:


    If we are talking about the WndProc function and the way how the window manager works, I am curious why the following thing happen:

    For example: you open up a window/dialog (e.g. the “Date and Time Properties” dialog) which draws something on the client area/update controls of the window let’s say every second. Now, if you press the “X” button and !keep! the mouse button down, the update of the window including its controls will stop, even if you move the mouse cursor from the “X” button, but keeping your mouse button down (I am not talking about multithreaded updates now). What is the technical background of this behavior? (the same happens in case of the “_”, “[]” and “?” caption bar buttons as well).


    [Please wait for the suggestion box to open. Oh, and in the meantime, you may discover that I discussed this exact topic four years ago. -Raymond]

Comments are closed.

Skip to main content