Does someone know a message that gets send at the end of a resizing event (like double clicking app bar, maximize button click, drag to the top of the screen, ...), a good example is WM_EXITSIZEMOVE, but it's only at the end of the dragging of the window size bar.
So my question is, does it exist a message that gets called when any sizing event has occured, at the end of it (not like WM_SIZE)?
You'll get a WM_WINDOWPOSCHANGED message with the SWP_NOSIZE flag cleared at the end of any sizing event. There's no other message that indicates sizing has finished other than WM_EXITSIZEMOVE which indicates the end of a modal moving/sizing loop. If you get WM_WINDOWPOSCHANGED without previously getting WM_ENTERSIZEMOVE then you can assume you're not being resized modally.
Related
I have a main window which allows to display a child modal dialog. That dialog window is created based on the resource file using DialogBox function. It contains a few controls and a horizontal splitter which are repositioned/resized when handling WM_SIZE and WM_MOUSEMOVE messages. I use BeginDeferWindowPos, DeferWindowPos and EndDeferWindowPos functions. It looks like that everything is repainted correctly. Should I also call InvalidateRect after EndDeferWindowPos ? Is there any scenario where it may be necessary ? I don't handle WM_PAINT message.
The documentation for the DeferWindowPos function would strongly suggest that, so long as you don't have the SWP_NOREDRAW bit set in the uFlags argument, you do not need to call InvalidateRect after you have called EndDeferWindowPos:
SWP_NOREDRAW 0x0008 Does not redraw changes. If this flag is set,
no repainting of any kind occurs. This applies to the client area, the
nonclient area (including the title bar and scroll bars), and any part
of the parent window uncovered as a result of the window being moved.
When this flag is set, the application must explicitly invalidate or
redraw any parts of the window and parent window that need redrawing.
I am developing a form with custom painting and sizing of the non client area. I am handling all of the appropriate NC window messages and everything is working great except for a certain sequence of actions. If the form is maximized, minimized and then click the task bar to maximize again, I do not receive a WM_NCCALCSIZE message. I receive the message when the form is maximized and minimized but not when maximized from the taskbar. My problem is that I am calculating the title bar rectangle when receiving the WM_NCCALCSIZE message, so when I redraw after this sequence, my title bar rectangle is the size of the task bar window of the minimized form. There are several places I could put in a hack to recalculate the title bar rectangle when painting, etc, but I'd prefer to find the intended method for calculating the non client area in this situation. Anyone know how or when I am supposed to recalculate the non client area?
While resizing win32 window, with OpenGL context, it just shows black on the newly exposed area.
I do get WM_PAINT message while resizing, and I do try to render new content, but it seems as if SwapBuffers does nothing, while resizing.
How should window resizes be handled correctly, so that there is no "broken" content while resizing?
This usually happens if you have a background brush configured for your window's class (see the WNDCLASS or WNDCLASSEX structure). If there's a brush, the system will clear the window right after each redraw step, then send the WM_PAINT. In case of V-Synced SwapBuffers your picture may have been overdrawn by the next resizing step before the buffer swap happened, or just right after it, but before that part of the screen was sent to the display device.
Either way, the solution is to set the background brush of the window to NULL. Also tinkering with the WM_ERASEBKGND message handling may give results.
EDIT due to comment
If the content of the last frame stays visible, you probably just don't react to resizing with a redraw. The easiest solution to this is calling the drawing function from the WM_SIZING (or the WM_SIZE, just try both) message handler.
In almost any Windows application, I notice that holding the mouse button down in a non-client area causes the painting to stop. Why is this required?
For example, I have a Managed Direct 3D application which displays a spinning cube. If I place the pointer over the title bar and hold the mouse button down, the cube ceases to spin even though I have not coded any such condition into my loop.
Why is painting halted? What are the benefits? Most importantly, how can I work around this?
When you click on the title bar, there's a brief pause while the window manager tries to determine whether or not you're clicking or beginning a drag (moving the window). If you're still holding down the button, then it's a drag: the window manager sets up its own message loop and pumps messages until you release the mouse. Your window should still be able to process messages, because they'll still be dispatched, but if your animation depends on a custom message loop then you'll be stuck 'till the modal drag loop ends.
Work around it by triggering your animation in response to messages: a timer seems like a good choice to me.
Usually, when a user holds the mouse pressed over a button, moves the mouse away from the window, and then releases it, the button can tell that the mouse has been released even though the release has actually occured outside the window.
When I inspect mouse clicks in my window, how can I imitate the same behavior?
When a mouse button being pushed down over the window I get the WM_XBUTTONDOWN message, but Windows don't treat it as if anything is logically being "clicked", so after the mouse leaves the window, no further messages will arrive at the window, which results in a "lost" WM_XBUTTONUP message.
When you receive the button down, you capture the mouse. That means that all the mouse events until releasing the capture will be reported to the window that captured the mouse.
See the documentation here. You also have a link to an example from that page.
Use the DragDetect() function.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dragdetect?redirectedfrom=MSDN