I have a dialog-based MFC C++ app. My dialog displays a number of "pages" (similar to a tab page or property dialog box).
I display each "page" by displaying a Child window over the top of the parent's client area. This works fine on Vista until I then open another window on top of the child.
Vista then seems to draw a thick white rectangular frame within my parent dialog box which paints over the top of my "page" child window(s). If I move another window over the top of this white rectangle, it will repaint the obscured area just fine.
Can somebody please tell me what is going on? Is Vista trying to clear my non-client (frame) area using incorrect coordinates perhaps?
My parent dialog is a skinned class derived from CDialog which handles the painting of my own window titlebar and frames. I've found that if I don't call CDialog::OnNcActivate() within my own OnNcActivate() method, the white rectangle doesn't appear. Of course if I do this then I can't use my child windows.. but OnNcActivate would appear to be related to the problem.
I've figured out the problem.. I shouldn't be calling CDialog::OnNcActivate() - I should have just been returning TRUE instead. All working fine now.
Related
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 a Parent window(derived from CView) which has 3 child windows.
1)Status bar like window.
2)Custom Display window.
3)Custom Dynamic GDI layout window.
All derived from CWnd.
I have created the child windows with WS_CHILD|WS_VISIBLE .
Out of the three child windows 2 windows are fixed on the Parent window.
Third window is a dynamic window which gets created and launched for a click event on status bar window. When a Third window is being displayed it is top of the Display window.
Problem :
When my Dynamic GDI layout is launched and displayed as topmost. Any part of the Display window gets updated then corresponding Dynamic windows screen gets erased.
So for a small region of Display window screen update erases my dynamic windows screen .
Dynamic window gets redrawn when i minimize and restore the entire application window.
PLease let me know how i can avoid my topmost displayed window getting erased when the other sibling window below that gets updated.
Thanks in advance.
currently I've this but it doesn't put my window behind the desktop
SetWindowPos(hWnd,HWND_BOTTOM,0,0,SCREEN_WIDTH,SCREEN_HEIGHT,SWP_FRAMECHANGED);
ShowWindow(hWnd,SW_SHOWNOACTIVATE);
i want to put my window behind every window even the taskbar and desktop icons window
please help me how can i do this
thanks in advance
The Desktop is a ListView control, and the desktop icons are its list items. Top-level windows can be made children of that ListView window, but it is impossible to place a child window between the ListView's background and its list items. The only way to make anything appear behind the items is to draw directly on the ListView's background, such as by subclassing it to intercept its WM_ERASEBKGND and WM_PAINT messages.
I am making an SDI MDF application that uses a frameview to provid the user with a set of controls (buttons, editboxes and such). The view also owns a set of CDialogs used to desplay aditional controls that can be can be shown or hidden via a tabcontrol and other means. Untill recently the dialogs have been staticly placed at creation to be in their proper location on the screen but I wanted to add a dialog that the user could move around but is still a child of the view. When I created a dialog with a caption and sysmenu that the user can move around the issue I am running into is that when the window is placed over another control owned by the view, (lets say a button) when the paint method is called on the button, it draws over the dialog. The dialog is still on top and the dialogs controls can still be interacted with but the button is drawn over them untill the dialog is repainted. I have tryed to change the clipchild and clipsiblings settings of the dialog and have been able to get the dialogs to properly clip eachother but can not seem to get the child dialog to properly clip the parent view controls. Does anyone have any ideas on what setting might fix this clipping issue.
C++
I have a modal child window that can be launched form a main window. The application runs on a Citrix server and when the user is on dual monitors, she can drag the child window to the secondary display and somehow Windows saves this position. When she moves to a workstation with a single display, she complains that the application is freezing when in reality the child window is off the screen and can be brought to the main display with some key combinations. Is there a way I can programmatically force the child window to always open on the screen where the parent window is located?
You can try calling CWnd::CenterWindow which will just position the window in the centre of the main monitor (usually above the parent window).
You should override PreCreateWindow and modify the the respective entries in the CREATESTRUCT to force the window into the visible area. Guidelines for positioning a window can be found at the MSDN ("Positioning Objects on Multiple Display Monitors").