Attempting to simulate client area based window dragging by returning HTCAPTION under a WM_NCHITTEST (excluding HTCLIENT & appropriate areas) works flawlessly when used with a parent window - however presence of child windows such as tabs placeholder windows, even when set to the extended style WS_EX_TRANSPARENT, cause clicks to fail to pass WM_NCHITTEST messages to the parent window (and attempting to process local WM_NCHITEST messages in a similar fashion produces the expected effect of dragging the child window around the parent rather than the parent itself).
Given that every area in that tab child window appears to be considered to be client area, processing WM_LBUTTONDOWN instead appears to produce the desired effect (see below):
case WM_LBUTTONDOWN: {
SendMessage(mainWnd.hWnd, WM_NCLBUTTONDOWN, HTCAPTION, lParam);
break;
}
Where mainWnd.hWnd is the parent window handle (hWnd is a member of a designed window properties helper class)
Although this produces the desired effect, I'm confused at whether WS_EX_TRANSPARENT is actually meant to allow clicks to pass through to underlying windows, and whether there is a more appropriate solution?
Have you tried returning HTTRANSPARENT from WM_NCHITTEST for the tab control? I think that should propagate the message to the parent window.
WS_EX_TRANSPARENT has to do with how the window is painted afaik.
Related
I have a LayeredWindow GUI that contains some child's and all of them contains the WS_EX_TRANSPARENT style.
The style is used to be able to remove their background.
When i move the mouse over the GUI only the LayeredWindow receives the message WM_MOUSEMOVE.
I tried calling ChildWindowFromPointEx using the XY pos got from the WM_MOUSEMOVE lParam
to detect the control being hovered, but the API didn't recognize any of the controls belonging to the child GUI's.
Docs says:
The search is restricted to immediate child windows. Grandchildren and deeper descendants are not searched.
The other option i tried was EnumChildWindow and compare each control rect to the XY position of the message, this method is using around 1% of CPU only from moving the mouse.
I wonder if there's any 'better' option?
According to the Doc:Layered Windows
Hit testing of a layered window is based on the shape and transparency
of the window. This means that the areas of the window that are
color-keyed or whose alpha value is zero will let the mouse messages
through. However, if the layered window has the WS_EX_TRANSPARENT
extended window style, the shape of the layered window will be ignored
and the mouse events will be passed to other windows underneath the
layered window.
You could try to use GetCursorPos function to get the position of the mouse cursor, in screen coordinates.
I have a c++ Win32 application with a node-based GUI where I create a dynamic combobox with CreateWindowEx when the user presses a certain key within the GUI. I want the user to be able to click outside of the combobox Rect in order to make the combobox disappear.
To do this, I'm currently destroying the combobox inside a WM_KILLFOCUS notification of its DlgProc (so any click outside of it destroys it). However, it seems that the WM_KILLFOCUS notification is sent anytime one of its child windows gains focus. For example, if I click in the combobox's edit text region, the combobox itself loses focus since that child gains focus. Given my setup, this causes the combobox to be removed when clicking within it's Rect.
How can I prevent this behavior? Basically I want to be able to detect when anything other than the combobox or its child windows gains focus, rather than simply detecting if the combobox itself loses focus.
You can determine, whether focus moves to a different control from inside the WM_KILLFOCUS handler. This message receives
[a] handle to the window that receives the keyboard focus.
through its wParam argument.
Use the CB_GETCOMBOBOXINFO message to retrieve a COMBOBOXINFO structure, that contains window handles to all contributing windows (hwndCombo, hwndItem, and hwndList). Comparing the wParam value to all of those window handles allows you to determine, whether focus moves inside the combo box or outside.
While this answers the question that was asked, the real solution would be to handle the CBN_KILLFOCUS notification instead. It is sent to the control parent when the combo box loses keyboard focus, ignoring focus change events internal to the combo box control.
my question is about how to properly repaint a child control after changing its text (in this case a checkbox).
Important to tell:
the checkbox is subclassed and gets painted in WM_PAINT &
WM_ERASEBKGND returns 1.
Window does not use WS_EX_COMPOSITED, WS_EX_LAYERED or WS_CLIPCHILDREN.
Checkbox does not use WS_EX_TRANSPARENT.
When I call InvalidateRect() on the checkbox, it has a grey background (image 2).
When on the other hand I call InvalidateRect() on the parent window, it behaves like I want to (image 3)
I think the second case works because also an WM_PAINT gets sent to the parent window instead of just WM_ERASEBKGND.
In the first case I don't understand why WM_PAINT doesn't get sent to its parent window OR why WM_ERASEBKGND does gets sent to the parent window.
Conclusion: To repaint a child control do you have to use InvalideRect() on the parent instead of the child?
Edit: Turns out the parent window receives a WM_ERASEBKGND message after I call ::SendMessage(hWnd, WM_SETTEXT, NULL, (::LPARAM)text.c_str()); on the checkbox. It was not because of the InvalidateRect() call on the checkbox.
I expect this is because of when you want to draw the checkbox inside the parent procedure. But why doesn't it then also generate a WM_PAINT for the parent window?
Initial Checkbox
After calling InvalidateRect(hWnd, 0, true) on the checkbox
After calling InvalidateRect(::GetParent(hWnd), &checkboxRect, true) on the parent window.
I tried to create button (child window) inside WM_NCCREATE message, and its position seemed to be created respected to screen coordinates, rather than client coordinates. At first, I thought WM_CREATE and WM_NCCREATE provide us the same handle to window, but this seem to be untrue. Therefore, can anyone explain me the differences between WM_CREATE and WM_NCCREATE messages? Also what are the differences between handle to window in WM_CREATE and in WM_NCCREATE?
WM_NCCREATE is an example of an arms race in progress. It seems to have been introduced to serve a need where DefWindowProc (or the base window proc of a commonly subclassed window) needed to perform some initialization perhaps before WM_CREATE was processed (or to make up for the fact that many window implementations handle WM_CREATE directly and return TRUE rather than passing it on to DefWindowProc).
WM_NCCREATE therefore is the message you should respond to if you are implementing a default window procedure, that needs to perform initialization before the users window proc handles the WM_CREATE message. WM_NCCREATE also MUST be passed on to the appropriate DefWindowProc, probably before you do your own processing as some lower level aspects of the window are clearly in an uninitialized state before WM_NCCREATE is processed.
If trying to guarantee first-look processing is NOT your consideration, then WM_CREATE is the appropriate place to perform your window initialization: All other layers that might have jist-in-time setup via WM_NCCREATE have been done, and the window is in a stable state wrt things like its non client metrics, screen position etc.
Or: If you don't know why you should use WM_NCCREATE over WM_CREATE, then you should not be using WM_NCCREATE.
The WM_NC messages are for the non-client area, i.e. the window border and caption. For your needs you are not interested in these non-client messages.
Per MSDN:
WM_NCCREATE:
Sent prior to the WM_CREATE message
when a window is first created.
Return Value:
If an application processes this
message, it should return TRUE to
continue creation of the window. If
the application returns FALSE, the
CreateWindow or CreateWindowEx
function will return a NULL handle.
WM_CREATE:
Sent when an application requests that
a window be created by calling the
CreateWindowEx or CreateWindow
function. (The message is sent before
the function returns.) The window
procedure of the new window receives
this message after the window is
created, but before the window becomes
visible.
Return Value:
If an application processes this
message, it should return zero to
continue creation of the window. If
the application returns –1, the window
is destroyed and the CreateWindowEx or
CreateWindow function returns a NULL
handle.
This device context includes the window title bar, menu, scroll bars, and frame in addition to the client
area. Applications programs rarely use the GetWindowDC function. If you want to experiment with it,
you should also trap the WM_NCPAINT ("nonclient paint") message, which is the message Windows
uses to draw on the nonclient areas of the window.
from:《Programming Windows Fifth Edition》 -Charles Petzold
So I think it's believable, although MSDN didn't say it。
Not sure why you're creating a button in the WM_NCCREATE -- because the window onto which the button will appear doesn't exist yet, hence (I believe) the destop coords. WM_NCCREATE gets sent to you when the 'non-client' areas of the window are about to be created (non-client areas such as the window's border, title bar, etc.)
Are you needing to put a button on the non-client area? If the answer is no, then why not do the button create inside
WM_CREATE.
If you have to create the button for some reason inside WM_NCCREATE, then why not store the window handle returned by your Createwindow() call. Then, inside your WM_CREATE message handler, grab that button's window handle and do a 'MoveWindow(...)' on it using the app window which you should now have coordinates to when you're in the WM_CREATE message handler.
I believe one of the parameters you can pass to your CreateWindow(...) call to create the button allows you to specify an 'SW_...'
flag, such as 'SW_HIDE' if memory serves me correct. So create but don't show the button in WM_NCCREATE handling if you must, then when WM_CREATE comes quickly afterward, do a 'MoveWindow(....window coords,......SW_SHOW,......) etc.
to position and make visible the button.
I want to allow a user to drag my Win32 window around only inside the working area of the desktop. In other words, they shouldn't be able to have any part of the window extend outside the monitor(s) nor should the window overlap the taskbar.
I'd like to do it in a way that does cause any stuttering. Handling WM_MOVE messages and calling MoveWindow() to reposition the window if it goes off works, but I don't like the flickering effect that's caused by MoveWindow().
I also tried handling WM_MOVING which prevents the need to call MoveWindow() by altering the destination rectangle before the move actually happens. This resolves the flickering problem, but another issue I run into is that the cursor some times gets aways from the window when a drag occurs allowing the user to drag the window around while the cursor is not even inside the window.
How do I constrain my window without running into these issues?
Windows are, ultimately, positioned via the SetWindowPos API.
SetWindowPos starts by validating its parameters by sending the window being sized or moved a WM_WINDOWPOSCHANGING message, and then a WM_WINDOWPOSCHANGED message notifying the window proc of the changed size and/or position.
DefWindowProc handling of these messages is to, in turn, send WM_GETMINMAXINFO and then WM_SIZE or WM_MOVE messages.
Anyway, handle WM_WINDOWPOSCHANGING to filter both user, and code, based attempts to position a window out of bounds.
Keep in mind that users with multi-monitor setups may have a desktop that extends into negative x- and y-coordinates, or that is not rectangular. Also, some users use alternative window managers such as LiteStep, which implement virtual desktops by moving them off-screen; if you try to fight this, your application will break for these users.
You can do this by handling the WM_MOVING message and changing the RECT pointed to by the lParam.
lParam: Pointer to a RECT structure with the current position of the window, in screen coordinates. To change the position of the drag rectangle, an application must change the members of this structure.
you may also want to handle WM_ENTERSIZEMOVE to know when the window is beginning to move, and WM_EXITSIZEMOVE
WM_GETMINMAXINFO is what you seem to be looking for.