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.
Related
When I call SetParent() on a child window passing hWndNewParent as null, the child window now has it own window, however I can't move it anymore, and its also moved to 0x0.
Is there any window style or something else I could apply/do to make this able to move the window?
Edit:
I was able to get the window moving again by disabling the window style: WS_DISABLED and enabling WS_DLGFRAME / WS_BORDER.
Another issue: the window doesn't respond to clicks. When I click the empty area left in the parent window, the click does work in the child window, but when I click in the child window itself, the clicks don't work. They are on the same process.
I want to create a window with two child windows. Only the background of the top child window is transparent. I can directly see the background of the parent window and not the content of other child windows.Like the picture, A is parent, B is child 1, C is child 2.The background of child 2 is the same as parent.enter image description here
A-a-m,
You paint background on child window by yourself.
There is method OnPaint (in MFC) or message WM_PAINT.
And you should draw transparent background (it means to draw nothing).
Does it work?
If you use non-standart framework to create windows, you should specify background is painted programmatically.
A few options to experiment with:
If in your open source UI framework you can remove the WM_PAINT
handler entry in the DefWindowProc then you could do that.
Handle the WM_PAINT message yourself and do nothing in the handler except clear any flag that indicates that the client area
needs to be re-drawn. You'll need to find something equivalent to
ValidateRect.
Both of these methods MIGHT cause non client areas like the window frame to artifact within the client area as you move window C around but I can't be sure.
I have some window. User can drag it, resize etc. At some point there can be a message that should be shown in modal window. I'm creating such a window as child and setting parent window to disabled. Everything works ok except the case when I'm dragging a parent window during the child creation. I used spy to see messages and found that in that case my child window doesn't receives WM_ENTERSIZEMOVE message. It seems that parent's WM_ENTERSIZEMOVE blocks one for child. I tried to manually send WM_EXITSIZEMOVE for the parent but unfortunatelly this doesn't works.
Send the WM_CANCELMODE message to your parent window before displaying the dialog box.
Sent to cancel certain modes, such as mouse capture. For example, the
system sends this message to the active window when a dialog box or
message box is displayed. Certain functions also send this message
explicitly to the specified window regardless of whether it is the
active window. For example, the EnableWindow function sends this
message when disabling the specified window
So i have created a main window inside of which i have created a 2 child windows. They all have different WindowProcs. At the WM_CREATE message of the main window I am giving focus to one of the child windows with SetFocus(...). After I display a MessageBox from the child window proc the focus is set back to main window. How can I maintain focus on the child window?
When the message box window is destroyed, Windows makes another top-level window the active window. If that’s not what you want, it is up to you to respond to the WM_SETFOCUS message that your main (top-level) window will receive and use SetFocus() to direct the focus to the child.
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.