Dragging Dlg Box w/o content

[gelarimer]

How does one implement dragging a Dlg box without its content in Win32 code? The WM_MOVING message allows tracking of the drag rectangle, butcould not find anything in the SDK about dragging without content. The reason I would like to do this is to prevent thelarge number ofWM_PAINT messagesthat are sent during a Dlg box drag. Thanks for any pointers.

[Jugoslav_Dujic]

First, have in mind that there's system-wide setting "Show window contents while dragging" in display options, that should not be overriden without good reason. Second, as far as I can tell, WM_PAINT is not send to the window being dragged (as it's topmost and ), but only to the windows beneath it. WM_PAINT is (should be) normally cheap by means of execution time, so I don't see why would you like to do it -- would you please clarify?

Reading between lines, if the window beneath is yours (not of another application) and you're seeing lots of flickering during drag of another window over it, you're asking a wrong question -- rather, it should read "how do I make my WM_PAINT handling more efficient?". You should definitely use double-buffering for any non-trivial drawing. (I have couple of examples around, but I'd still wait for your answer in case I'm barking at a wrong tree).

[gelarimer]

Thanks for the info and reply.

I manged to create a Fortran routine that mimics thesystem drag w/ocontent and without callingSystemParametersInfo(SPI_SETDRAGFULLWINDOWS, false, NULL, 0).Thecode is relatively simple: use the WM_WINDOWPOSCHANGING message and set the WINDOWPOS structflag, SWP_NOMOVE, then create a rectangle the size of the wnd to take the place of the wnd and use SetRop2(hDc, R2_NOTXORPEN) to overwrite the last rectangle and to create a new rectangle as the cursor moves over the screen. Works fine except forone minor bug.

Yes, I am trying to reduce the number of WM_PAINT messageswhichcalculate the entire screen graphic so that just a few pixels that are uncovered by a Dlg Box can be repainted as it is dragged across the screen. So any info would be appreciated.

Another related problem: I need to be able to track thedummy window created by the Windows Systemif the "Show window contents while dragging" check box is unchecked in Control PanelDisplay.This disables the WM_WINDOWPOSCHANGINGmessage for the dlg box. Tried to capture the mouse but this did not work either because the WM_MOUSEMOVE mesg also appears to be disabled. Any ideas on how to trackthe system generatedwnd w/o content would be appreciated!

Thanks.

[Jugoslav_Dujic]

I think you're on a wrong track. You're solving (in a complicated manner, at that) the problem if your own dialog is dragged over the main window -- but what if you e.g. take a (non-maximized) external window and drag it over the application? You can't control that, and it will certainly generate a lot of WM_PAINT messages.

I assume the problem is that your WM_PAINT code is sluggish, as it happens when the drawing is complicated and all rendering is in CASE(WM_PAINT). The solution to that is to use "double-buffering" -- i.e. draw on an memory (off-screen) DC and just BitBlt its contents onto screen on WM_PAINT. See e.g. XDblBuffer samples on my home page.

[gelarimer]

You are correct, and your sample code makes things a lot clearer. Thanks.

Still have a question about tracking the'Empty Window'if user unchecks the"Show Window Contents While Dragging"in Control PanelDisplayEffects. Not sure what type of control the Empty Window is, or if it is a control at all.

I have a Win32 program that tracks the position of a Dialog Boxanddraws a rectangle on thescreen (showingdocked position if user releases mouse button) when the dlg reaches the right border of the app. Tracking works fine until the "Show Windows Contents While Dragging" check box (in Control PanelDisplay) is unchecked by the user.

Apparently theWM_WINDOWPOSCHANGING mesg isNot sent (which I use for tracking).Tried capturing the mousein case(WM_ENTERSIZEMOVE) in the Dlg proc., and then monitoring the cursor movement in the MainWndProc, but this seems erratic, not sure why. Anyinfo ipspointerson what the system generated Empty Window is and how to track it would beappreciated.

Thanks.

[Jugoslav_Dujic]

I did investigate "Empty windows" at a time, but it was fairly long time ago. To be honest, I just dismissed the problem, as modern graphic cards are powerful enough that only few users might want to select option.

IIRC (and also according to MSDN), WM_WINDOWPOSCHANGING is sent only when the window is being sized by means of an API call rather than by mouse-dragging. Apparently, it is being send in case of "Non-empty windows". However, WM_MOVE should be received in any case (I'm not sure, though, about "empty" ones; I kind of recall that they don't receive WM_MOVE either) -- did you try that?

I believe that "Hide Window contents while dragging" is implemented as a system hack (i.e. direct drawing on display DC like you did yourself). I'm not too familiar about it, but you might ask as well in some Win32 forum (e.g comp.os.ms-windows.programmer.win32 Usenet group).

[gelarimer]

I did try WM_MOVE and that was not received until the mouse button was released with the system generated Empty Window. I will post at the Google group you suggest.if I learn any more, I will post it here.

Thanks for the help, sample code, and tips.

[Jugoslav_Dujic]

I did try WM_MOVE and that was not received until the mouse button was released with the system generated Empty Window.

Yes, now I recall too--I was implementing a "rubber-band", which is a line that connects a moveable popup window's top left corner with its anchor on the map in the main window. The rubber band was redrawn on WM_MOVE, but if "hide window contents" was checked, it wouldn't update until the move was completed. At the end, we shrugged and documented that we recommend having the checkbox off -- I recall that NO messages were sent to the window during the dragging.