According to Win32 official docs:
Window Styles
Constant name
Constant value
Description
WS_OVERLAPPED
0x00000000L
The window is an overlapped window. An overlapped window has a title bar and a border. Same as the WS_TILED style.
What is the point of a zero flag? In C programming, it doesn't make sense to me. Only non-zero values make sense for additive/accumulative flagging.
I guess one way to look at it is that OVERLAPPED is the default style, unless you modify it with those additive flags. This #define gives you a readable way to express this in code, for example:
CreateWindowA("some_class", NULL, WS_OVERLAPPED, ...)
That's clearer than just passing 0. It makes a lot less sense if you start combining it with other flags, of course.
Related
GtkEntry get his alignment property from xalign parameter. but when you start typing
in some RTL language (ex. Arabic) it reverses the alignment (this feature is also noted in GTK reference). how can I stop this feature and make the alignment permanent, independent of input language?
I know some solution in WINAPI with enum all visible window to check intersect with my window...
But I need crossplatform solution for Qt (3 or 4 - no metter), maybe someone can help me with it?
Thanks.
To simply check if your window is active/has the keyboard focus you can check whether the Qt::WindowState is Qt::WindowActive.
To check your window for overlappings/intersections with other windows (I think that was your question) I can only think of using a little work-around.
The QWidget class has a function QWidget::visibleRegion() which returns a QRegion. Basically this region is the space in which paint-events can occur, that means that this is the space not covered by anything else. You can check whether the size of this region roughly matches the size of your window to see if there is any space covered by something else.
I didn't test this, so I can't tell you if it works for all platforms you need it to work on.
Edit: According to your comment:
This is what I found in the qt 4.6 reference about visibleRegion():
Returns the unobscured region where
paint events can occur. For visible
widgets, this is an approximation of
the area not covered by other widgets.
So if the size of this unobscured region is approximately the size of your window, then your window isn't covered by anything.
The GetClientRect function, according to MSDN, is actually only good for determining the client width & height, since left & top are always zero. Is there a way to get the complete client coordinates, including left & top (either in screen space, or in window space)?
Call ClientToScreen on the top left and bottom right of the returned RECT. If you're using MFC, CWnd has a helper overload of CWnd::ClientToScreen that will do this transparently for you.
Maybe you are needing GetWindowRect.
You're looking for the GetWindowPlacement function. This function returns a WINDOWPLACEMENT struct which has an rcNormalPosition property which specifies the window's position when it is in the normal (rather than maximized or minimized) display state.
EDIT: itowilson's answer is actually cleaner because the WINDOWPLACEMENT structure also contains a bunch of data you don't need.
I have a dialog that resizes. It also has a custom background which I paint in response to a WM_ERASEBKGND call (currently a simple call to FillSolidRect).
When the dialog is resized, there is tremendous flickering going on. To try and reduce the flickering I enumerate all child windows and add them to the clipping region. That seems to help a little -- now the flickering is mostly evident in all of the child controls as they repaint.
How can I make the dialog flicker-free while resizing? I suspect double-buffering must play a part, but I'm not sure how to do that with a dialog with child controls (without making all child controls owner-draw or something like that).
I should note that I'm using C++ (not .NET), and MFC, although pure Win32-based solutions are welcomed :)
NOTE: One thing I tried but which didn't work (not sure why) was:
CDC memDC;
memDC.CreateCompatibleDC(pDC);
memDC.FillSolidRect(rect, backgroundColor);
pDC->BitBlt(0, 0, rect.Width(), rect.Height(), &memDC, 0, 0, SRCCOPY);
Assuming that "FillSolidRect" is the erase of your background then return TRUE from the WM_ERASEBKGND.
To do the double buffering that you are almost doing in your code fragment, you will need to use CreateCompatibleBitmap and select that into your memDC.
Try adding the following line to your OnInitDialog function:
ModifyStyle(0, WS_CLIPCHILDREN, 0);
Do nothing in the WM_ERASEBKGND handling and do the erase as part of your main WM_PAINT. You can either paint smarter so that you only redraw the invalid areas, or more easily, double-buffer the drawing.
By not doing anything in the erase background, you have all your drawing code in one location which should make it easier for others to follow and maintain.
If you are targeting WinXP or higher, you can also use the WS_EX_COMPOSITED style to enable double-buffering by default for top-level windows with this style. Bear in mind this has its own set of limitations -- specifically, no more drawing out of OnPaint cycles using GetDC, etc.
you can set parameter of your call to InvalidateRect method as false. This will prevent you to send WM_ERASEBKGND when the window will redraw.
Double buffering is indeed the only way to make this work.
Child controls will take care of themselves so long as you make sure CLIPCHILDREN.
Is there a way to change the colors used by plain Win32 menus (background, text, and highlight) for a single process, without using SetSysColors?
(SetSysColors does a global change, which is bad, and if you crash or forget to set the colors back with SetSysColors again before exiting, they will not be restored until you logout.)
The SetMenuInfo() API is your friend. It lets you apply any brush to paint your menu's background.
Something along these lines should solve your problem:
MENUINFO mi = { 0 };
mi.cbSize = sizeof(mi);
mi.fMask = MIM_BACKGROUND|MIM_APPLYTOSUBMENUS;
mi.hbrBack = hBrush;
HMENU hMenu = ::GetMenu(hWnd);
SetMenuInfo(hMenu, &mi);
If I believe your comment to Rob, it is for a skinned application, with special look and feel. So the way to go is probably indeed, as ferek points out (in an unfriendly way...) to use owner-drawn menus: you will be able to define precisely their look.
I have to ask, why? Adopting the regular Windows look-and-feel is good; it means users can be confident that there are consistent elements in your user interface, onto which they can map their experience using other software for the platform.
[I'm probably preaching to the converted, of course, but I thought I'd make the point so anyone who reads an answer for this doesn't start making all their menus sky-blue-pink 'cause it looks pretty.]