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.
Related
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.
I'm creating a window in C++ with that code:
HWnd = CreateWindow(wc.lpszClassName,
"myapp",
WS_POPUP |WS_VISIBLE,
10, 10, 1000, 800, 0, 0, hInst, NULL);
It appears as I want but when I maximize it with like this:
ShowWindow(hwnd, SW_SHOWMAXIMIZED);
then it's like a fullscreen window so that the taskbar is hidden.
I think it's because it is a POPUP window but this is like I want it to appear.
Do I need to create my own maximize function or is there a parameter to avoid that ?
Thanks
You can add WS_CAPTION | WS_SYSMENU | WS_MAXIMIZEBOX style.
If you want your window to be without caption then you will need to adjust window size manually to fit into desktop work area that you can query using SystemParametersInfo specifying SPI_GETWORKAREA flag.
This is a feature where the Taskbar will get out of your full-screen application:
If you want to create a fullscreen window that covers the taskbar, just create a fullscreen window and the taskbar will automatically get out of the way.
I’ve seen people hunt for the taskbar window and then do a ShowWindow(hwndTaskbar, SW_HIDE) on it. This is nuts for many reasons.
Don’t do any of this messing with the taskbar. Just create your fullscreen window and let the taskbar do its thing automatically.
Since this is Stackoverflow, a combination of Wikipedia and Reddit, i want this relevant information saved for the next guy asking this question.
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 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.
If you look at the windows of the browsers Firefox, Chrome or Opera, you'll notice that their windows
have minimize/maximize/close buttons
are resizable
but have no title bar
I'm interested: how can I create such a window?
What I have already tried:
I looked around on StackOverflow (and googled, too), and found this: opening a window that has no title bar with win32
Unluckily, this didn't help completely:
The first step was to extend the solution proposed on opening a window that has no title bar with win32
hWnd = CreateWindow(szWindowClass, szTitle, WS_BORDER,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL);
SetWindowLong(hWnd, GWL_STYLE, WS_SIZEBOX);
// See remarks on http://msdn.microsoft.com/en-us/library/windows/desktop/ms633545.aspx
SetWindowPos(hWnd, 0,
0, 0, 0, 0, // Position + Size
SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);
Of course, this delivers no minimize/maximize buttons, but on the other hand, if I want minimize/maximize buttons, I have to do:
SetWindowLong(hWnd, GWL_STYLE, WS_SIZEBOX | WS_MAXIMIZEBOX |
WS_MINIMIZEBOX | WS_SYSMENU | WS_CAPTION);
Why does this combination seem to be necessary? First I probably want WS_MAXIMIZEBOX | WS_MINIMIZEBOX since I want these buttons.
But http://msdn.microsoft.com/en-us/library/ms632600.aspx says that if I set one of WS_MAXIMIZEBOX and WS_MINIMIZEBOX, I also have to set WS_SYSMENU. And when I set WS_SYSMENU, I also have to set WS_CAPTION but this is not what I want, because I wanted to avoid the title bar (indeed: if WS_CAPTION is not set, no minimize/maximize buttons are shown).
So what is to do?
The programs remove the non-client area (the title bar) and have a bunch of custom handling for reproducing the window buttons, icons, system menu etc. The benefit of this is that they can draw to the new "title bar", which is actually part of the standard client area, adding tabs or other custom controls.
The following two articles will show you how to do this on Vista and above (using the DWM):
Setting up a custom title bar on Windows Vista / 7
Setting up a custom title bar - reprise This one has a demo app showing the result of a number of variations / options.
This is very complex to do and get right, so the above two articles are invaluable. The author must have put a lot of work into them! Both links have example code written in Delphi, but it should be easy enough to translate it to C++ - the concepts are identical, it's just syntax.
You might also be interested in general resources on Glass and DWM, since it's all closely related. You'll spot the above two links included in that list :)
You can create a window with or without caption - whatever is more appropriate from the point of view of desired customization (that is "without" is you want to do it "without title bar" as you say), and the important wart is that you take over painting non-client area - this is the key thing.
At this point, there is no one to paint your mimimize/maximize buttons already. It does not however mean that you have to do the painting right from scratch and mimic standard UI. There is DrawFrameControl and friends API where you can use DFCS_CAPTIONMIN argument and have minimize button painted for you. You will also want to respond to other non-client area messages, e.g. handle WM_NCHITTEST to tell Windows where your new window buttons are.
You might also want to check Visual Styles Reference to leverage theme-enabled drawing API such as DrawThemeBackground.
A simple example of this activity is putting an additional button onto caption, such as described in detail here: CCaptionButton (buttons for the titlebar).
I believe they create a normal window and then paint over the title bar with their custom widgets/tabs. This is evident in Firefox, as when it hangs you can see the normal Windows title bar appear over the tabs.