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").
Related
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.
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 am trying to implement a custom tab control in my win32 window, for that i have used a layered window which is child of the main app window (for the main tab control) and independent windows for individual tab items.
My problem: Whenever i move the main app window, the control window moves along with it (because its the child window) where as the individual tab item windows remain on their position. Can anyone guide me how to to get the tab items windows move along with the main app window concurrently? I can not set the item windows as child of the app, so please base your suggestions on that.
You should redesign your tab to be a child window. Otherwise your attempts to make it work is nothing but a desperate try to fix the thing made bad in first place.
Still if you feel like sticking the original plan, you need to hook/subclass the main app window and handle its movement and sizing messages (WM_MOVING and friends) so that your handler could update your popup/tab window position respectively.
We have an MFC MDI app that during the process of operation can set the focus on a given control, e.g. it might change the active tab if the result of the operation is more appropriate for a different tab.
If the app has focus when the SetFocus occurs this is fine, tab changes and the correct control has focus. However, if the app does not have focus (ie the user has clicked on another app while waiting for the operation to finish) the SetFocus on the child window causes an OnActivate to occur in the parent MDI frame and the app becomes the foreground window.
How do we SetFocus to a child window without the whole app from becoming the foreground window if the user is working in another app.
Did you try to change focus using CDialog::GotoDlgCtrl ?
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.