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.
Related
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.
I want to design a student registration and exam recording app using C++ MFC with a kind of child window containing buttons edits and other common controls which is displayed on the app client area, and can be removed and replaced with another one by clicking a button. Thats the problem i face now( The GUI ). I came from JAVA background where this can be done by creating a JPanel as a container for the buttons, combo boxes and text fields controls. the panel is displayed on the client area and can be removed and replaced with another panel containing a new set of controls. I tried learning CView but it keeps talking about documents and views that displays untitled document as in word processing. Any pointer will be appreciated. Thanks.
After having searched and read a lot about my problem, i decided to go into win32 API where everything is possible depending on your awareness.The solution is as simple as creating a main window and creating any number of child windows who uses the main window as parent and all has a hiden window attribute. Then you can create controls on each child window. To switch between the child windows I did this: ShowWindow(childWindow1, SW_HIDE); ShowWindow(childWindow2, SW_SHOW);. thats it, only that the repaint process after restore does not repaint the child window's controls and its child window.
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").
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.
I found the windows style WS_EX_TOOLWINDOW but this changes the title bar. Is there a way to not have the tasktray icon but keep the normal window titlebar?
You usually do want to do this if you have added an alternate means to restore the window - for example placing an icon in the notification tray.
The usual way of ensuring the taskbar does not display your window is to create it with a hidden parent window. Whenever a window has a parent, the parent window is used to create the button - hidden windows are not shown on the taskbar.
Also, WS_EX_APPWINDOW should be removed as that performs the opposite hint to the shell and forces the window onto the taskbar even if it would otherwise not have been shown.