In handling a WM_GETMINMAXINFO message, I attempt to alter the parameter MINMAXINFO structure by changing the ptMaxSize. It doesn't seem to have any effect. When I receive the WM_SIZE message, I always get the same value, no matter whether I increase or decrease the ptMaxSize in the WM_GETMINMAXINFO.
Are you sure your window is maximized? As per http://msdn.microsoft.com/en-us/library/ms632605(VS.85).aspx, MINMAXINFO::ptMaxSize controls the maximum size of the window wen maximized.
If you want to control the maximum tracking size of your window (the maximum size when the window is normal), you need to modify MINMAXINFO::ptMaxTrackSize.
Make sure you are handling the WM_GETMINMAXINFO message in the window procedure of the main application.
The message only makes sense when handled by the main frame window and will have no effect if the message is handled by one of the child window procedures.
A window must have the WS_THICKFRAME or WS_CAPTION style to receive WM_GETMINMAXINFO.
This is basically all you need to know.
Related
I need to know if it is safe to store some calculated non-client area RECT (not the window rect neither the client one, it is a based on some calculation) from the WM_NCCALCSIZE message and use it later in the WM_NCPAINT without the need to do the whole recalculation process again in WM_NCPAINT!?
i.e. is WM_NCPAINT always called immediately after WM_NCCALCSIZE?
I need to save the hassle of doing the recalculation process in WM_NCPAINT message, because DefWindowProc from WM_NCCALCSIZE already does all what I need to start my calculations based on what it does.
TIA.
i.e. is WM_NCPAINT always called immediately after WM_NCCALCSIZE?
I test this sample which provided by krsi, we can find that WM_NCCALCSIZE is always called before WM_NCPAINT, but this does not mean that no other messages were called in the middle. For example, when testing, after receiving WM_NCCALCSIZE, WM_PAINT will be called first, and then WM_NCPAINT will be called.
You seem to be customizing the non-client area, I think you can first read Nonclient Area.
In general, processing these messages for standard windows is not
recommended, because the application must be able to draw all the
required parts of the nonclient area for the window. For this reason,
most applications pass these messages to DefWindowProc for default
processing.
An application that creates custom nonclient areas for its windows
must process these messages. When doing so, the application must use a
window device context to carry out drawing in the window. The window
device context enables the application to draw in all portions of the
window, including the nonclient area. An application retrieves a
window device context by using the GetWindowDC or GetDCEx function
and, when drawing is complete, must release the window device context
by using the ReleaseDC function.
If you just consider whether the size of the custom client area will change when WM_NCPAINT is called, I can't give a suitable answer because I haven't seen your code and I don't know what kind of project you need to complete.
I just tested the sample in another link, the non-client area will always maintain the border size of 4pixel, and the calculation is also performed in WM_NCCALCSIZE.
I'm trying to prevent my rendering from stopping when my window is out of focus or resizing. In addition to the resizing, if I resize my window smaller, then bigger again anything that wasn't visible when it was smaller is now black. Is there any way to fix this?
There are really two distinct things going on here. The moving/resizing problem is caused by the windows DefWindowProc function which applications use to handle messages that aren't explicitly handled by the application itself. In the case of moving or resizing, it blocks, creating a new message queue to handle most messages, but there are a few that it will still dispatch to the application's main event queue, like WM_TIMER. You can find lots more information in this answer.
The second issue is that your program only "owns" the pixels inside your window, and only those that are not covered up by other windows. When you make the window smaller, the pixels at the edge need to be overwritten to show the window border or whatever's behind the window. When the window is made bigger, some drivers automatically set the newly acquired pixels to black, while others leave them at whatever they were before (usually part of the window border). The OS doesn't remember if those pixels had some specific color the last time the window was that size, because most of the time the program doesn't care. Instead, windows sends a WM_PAINT message to indicate that the application should redraw the window. Your program should either directly handle this, or use a library like GLFW that abstracts it. In addition, you need to handle resize events by calling glViewport with the new size of the window.
Does anyone know how to remove the focus rectangle on this item? I have used successfully the WM_UPDATEUISTATE message with buttons but it has no noticeable effect on syslinks.
I'm going to guess and say that because SysLink controls have a definite focused state (LIS_FOCUSED), they ignore the UI state flag which would otherwise make them suppress the focus rectangle.
If this is the case then I'd say you could use the LM_SETITEM message with LF_STATE to remove the LIS_FOCUSED state from the control. You would probably need to sub-class the control and do this immediately after it processes the WM_SETFOCUS message, although the control may set this state after other messages too so some experimentation would be required.
How can I resize my application's window when the taskbar's size has changed?
For example, when the taskbar has been reduced in size my window should increase in size to fill up the hole that was created. My window should never overlap the taskbar.
I was able to create the window in the correct place by calling CreateWindowEx with a position derived from calling SystemParametersInfo(SPI_GETWORKAREA, 0, &rectWorkArea, 0);
Now, when I increase the taskbar's size my window's size decreases automatically
without any code. But when I "go back", my window remains in its current position. How can I fix this?
Not judging if it is good or wrong idea (as standard applications just don't do it), I think it can be tracked by handling WM_SETTINGCHANGE in any top-level window.
Basically, I'm looking for a IsWindowMoving(HWND) Win32 API call. I need to know if the user is currently moving a window.
The window doesn't belong to me, so listening for WM_SYSCOMMAND / SC_MOVE or WM_MOVING isn't possible (I don't want to subclass or hook due to 32/64 interop).
You can do this with GetGUIThreadInfo - no hooking needed. Use GetWindowThreadProcessId to get the TID for your hwnd then check the GUITHREADINFO.flags and GUITHREADINFO.hwndMoveSize to see if your window is in a move / size loop.
If the window doesn't belong to you and you're not going to snoop messages, the best you can I think is get hold of a handle to that window. That limits you to whatever informational function calls exist which work on a handle. I know of no such call which can inform the user that the window is being moved.
You may be out of luck.
If you don't want to hook, subclass, or anything else like that, I think polling might be the easiest way left. Using GetWindowRect you can track the previous and current position and size of a window. Doing a delta will let you detect if the user is moving (or even resizing) the window. Since you are dealing with UI, there is no need to poll too quickly (even 2-5 times a second should be plenty).