If I handle WM_NCCALCSIZE for a window with the style WS_OVERLAPPED, I just simply return 0 when the WPARAM value is TRUE. This removes the window borders.
What is the difference between doing that, rather than creating a WS_POPUP window? Are the actual frames different if I try to extend the frames using DwmExtendFrameIntoClientArea? And when should I try to use each style?
WS_POPUP is not nearly as relevant as it once was, it is a hint to the OS that the window is not likely to be long-lived and thus to save the display area under the window rather than require repainting when the window is dismissed. The window handled by the popup menu loop for example, or dialogs. This used to be a major performance benefit (particularly in the days of win16) when used appropriately, I am not aware of any difference in the actual mechanics between overlapped and popup windows.
Related
In my app, I want to keep my window full screen. So I added resizing window function when received WM_DISPLAYCHANGE event.
In the resizing window function, I use EnumDisplayMonitors to get current size of monitor, the size is correct. Then I use SetWindowPos function to set my window size equal to the monitor. But after SetWindowPos called, I found my window is still a little smaller than the monitor size some time. It seems that the desktop is not ready enough. I also set SWP_NOSENDCHANGING flag in the SetWindowPos function but still not work.
Is there any way to solve this problem?
The usual approach to make a window full screen is not by reacting dynamically to WM_DISPLAYCHANGE or query the display dimensions. The canonical way to make a window full screen is to set its style to WS_MAXIMIZE | WS_POPUP | WS_VISIBLE its extended style to WS_EX_TOPMOST using SetWindowLong, followed by a call to SetWindowPos with flag SWP_FRAMECHANGED, then maximize it with *ShowWindowwith flagsSW_SHOWMAXIMIZED`.
I've spent many hours on google and haven't found any relevent results on this particular subject.
I have an application I am wanting to be minimized when the user clicks on it in the taskbar (if it's not already minimized). The problem seems to be related to the fact the window is borderless. When I set it to have a border, it minimizes just fine when clicking it in the taskbar, without any code intervention. But I need the window borderless because I'm making a "custom border" using the client area.
tl;dr how do I check if the current application is being clicked in the taskbar?
Many thanks!
Samuel
There is no need to tinker with the taskbar.
Just make sure you have the WS_MINIMIZEBOX|WS_MAXIMIZEBOX styles set for your window. Otherwise your window won't handle WM_SYSCOMMAND with a wParam of SC_MINIMIZE and SC_RESTORE.
Some resource editors like the one in Visual Studio make it impossible to set WS_MINIMIZEBOX|WS_MAXIMIZEBOX when you remove the standard window border. You may programmatically add the styles back like this:
DWORD style = GetWindowLong( hwnd, GWL_STYLE );
SetWindowLong( hwnd, GWL_STYLE, style | WS_MINIMIZEBOX | WS_MAXIMIZEBOX );
I need to create a window that acts like "normal" one, but without maximize button, and sizing border.
Searching through Internet, and studying MSDN, I have learned that natively achieving both is impossible.
There is no window style that does both ( I can disable maximize button, but that is not my aim; as for removing resizing options, I have found suitable window styles in the documentation ).
The closest description would be the dialogbox frame behavior ( no sizing border ), but with extra minimize button.
QUESTION:
Is there a way to achieve my goal some other way?
If yes, can you please provide links to tutorials or code examples? This would be the first time for me to do such a thing and could use all the help I could get?
An important note: I have found this example while searching for a solution, but it will not help me because I target Windows XP onwards.
Creating a window as below will give you a non-sizeable window with a title bar, a minimize button and an exit button.
dwStyle = WS_SYSMENU | WS_CAPTION | WS_MINIMIZEBOX;
hWnd = CreateWindow(szAppName, szTitle, dwStyle,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0,
NULL, NULL, hInstance, NULL);
See http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679%28v=vs.85%29.aspx
and http://msdn.microsoft.com/en-us/library/windows/desktop/ms632600%28v=vs.85%29.aspx
I suppose you are creating the window using CreateWindowEx. Then, if you omit both WS_MAXIMIZEBOX and WS_MINIMIZEBOX flags (the dwStyle parameter), the window will have only the close button (no minimize/maximize) buttons. If you ommit just WS_MAXIMIZEBOX, Windows draw the maximize box disabled to keep the graphics layout consistent for all windows. There is no way to change this behavior, and it can change in different versions of Windows (Win3.1, for instance, didn't draw the maximize button at all when the flags were set as mentioned.)
Resizable border is disabled by setting other frame than WS_THICKFRAME (ie. WS_BORDER or WS_EX_DLGMODALFRAME in the dwExStyle parameter).
You can also control the user sizing/moving of your window by intercepting messages WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGED, WM_ENTERSIZEMOVE, WM_EXITSIZEMOVE, WM_SIZING and WM_MOVING.
In theory, you can also completly change the appearance of the non-client area of the window, but it's hardly worth the effort, and it's questionable whether it's a good idea to fight with the default graphic layout of the operating system when all the developers and user are used to it and content with it. (In other words: if you don't want your window to be maximized, just omit the WS_MAXIMIZEBOX flag and leave it on the operating system how to realize this particular decision.)
I'm pretty sure it is documented on MSDN that the window style you want to OMIT is WS_THICKFRAME, since the Window Styles page says that a thick frame is a sizing frame.
I have an QML application (also tested it with QWidgets, same problem) and to make it borderless (but still support the native WM features like aero snap, etc) I followed this by implementing an QAbstractNativeEventFilter and responding to the WM_NCCALSIZE signal with zero:
switch(msg->message) {
case WM_NCCALCSIZE:
*r = 0;
return 1;
...
}
I also set some window flags which are not in the Qt Namespace with
SetWindowLong(hwnd, GWL_STYLE, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CLIPSIBLINGS | WS_BORDER | WS_SYSMENU | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_THICKFRAME);
This works fine until I move or resize the window which causes Qt to rerender and a unpainted area width the width of the title and the borders appears:
Before moving/resizing
After moving/resizing
I also found a workaround for this by adding the FramelessWindowHint flag in Qt:
window->setFlags(Qt::FramelessWindowHint | Qt::WindowSystemMenuHint | Qt::Dialog);
But now this margins occurs again when the window state changes (maximizing, minimizing, ...). By blocking the WM_SIZE event for example when SIZE_MAXIMIZED is the parameter the margin doesn't appear but then I also am not able to maximize the window from Qt. This means it is a Qt side problem.
I also noticed by inspecting the window style with winspector, that after I have maximized it a new property atom appears:
Can you help me fixing this?
I think using SetWindowLong on your window handle and using the Qt Window Flags/Qt Widget Attributes is asking for trouble. You can go and look at the Qt source to see what happens when processing those window flags.
When I've created frameless windows, I've usually done it to prevent moving and resizing, because I am managing all that separately.
One problem that I had related to it, was when the On Screen Keyboard came up and docked, it would resize my windows. So besides calling resize() I had to also use setFixedSize to prevent my widget from getting manipulated when the operating system attempted to change the size of the window.
So in other words, I would add an application wide QShortcut, listening for the snapping keyboard shortcuts and resize your window the way you want it to when it happens, if you are managing a frameless window.
Hope that helps.
I wonder if this was a flaw of Qt message relay, coz I met with a similar problem which occurs on nested windows. If you press SIZE_MAXIMIZE or SIZE_MINIMIZE button of the parent window, the child window sometimes is not able to receive WM_SIZE message. I suppose there are roughly two solutions: 1. Fix Qt, 2. Work it around.
Here I have a OGL rendering child window, sometimes even the WM_SIZE message is not correctly passed. That is, if you resize parent window, you get part of the client area black.
I just use a simple workaround to fix this, which check the current size with the cached one, and make a sort of manually resize myself.
I have a Windows console application written in C++ and want to hide/remove the complete title bar of the console window, including the close, min/max controls etc. I searched a lot but didn't found anything useful yet.
I inquire the console HWND with GetConsoleWindow and tried to change the console window style with SetWindowLong by removing the WS_CAPTION flag, but this seems to have no effect at all:
HWND hwnd = GetConsoleWindow();
LONG style = GetWindowLong(hwnd, GWL_STYLE);
style &= ~(WS_BORDER|WS_CAPTION|WS_THICKFRAME);
SetWindowLong(hwnd, GWL_STYLE, style);
SetWindowPos( hwnd, NULL, 0,0,0,0,
SWP_NOSIZE|SWP_NOMOVE|SWP_NOZORDER|SWP_NOACTIVATE
|SWP_FRAMECHANGED );
I also tried GetSystemMenu/RemoveMenu but this seems only to disable controls like the close button.
You can't. Generally the hWnd of a console window is not guaranteed to be suitable for all window handle operations as, for example, documented here.
You could try a complex solution involving hiding the console window (this is possible), and then setup a window (without the controls) that forwards appropriate events back and forth from the real console window. In particular GDI events to draw the console window contents in your fake console window, and interact with the scrollbar (which in turn adjusts the console...).
This solution is pretty far out, and quite technical.
You can use SetWindowLongPtr(hWnd, GWL_STYLE, WS_POPUP); , which will remove the caption/titlebar and the borders.
Warning: This does introduce a few glitches that I don't know how to fix (I guess they're cached borders?), but at least it does produce the effect that you want.
I think I would write/use two programs. One console program doing the work and a second program being a controllable console window running the first one. Most probably there are already existing console programs out there and some can be started without title bar? Or find an open source one and modify it.