MFC floating CDialog control clipping issue - mfc

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.

Related

Why does CToolTipCtrl parent matters?

Recently, I've got stuck over strange UI issue, found a solution, but still unsure about problem cause.
Preconditions:
MFC MDI application has 2 modeless dialogs opened, both has a child third-party grid and CToolTipCtrl. Dialog windows crosses each other borders (i.e. active dialog is overlapping part of inactive one). CToolTipCtrl is similar to example, the only tool set for tooltip is grid. Parent of tooltip is There is the corresponding dialog's grid, TTS_ALWAYSTIP style is set to allow tooltips on inactive dialog.
Issue:
When mouse is hovering on inactive dialog's grid, tooltip is appearing and inactive dialog is drawn over active one. In other words, inactive window is brought to top without activating. It's drawn completely, including caption, buttons, grid, etc.
I've checked Z-order and found that inactive dialog is still inactive, even when shown on top. No Z-order changed. Then I gathered message log using Spy++ for whole inactive dialog while tooltip is appearing and found no WM_ACTIVATE, WM_FOCUS, WM_MDIACTIVATE, etc. Then I performed search about how to bring window up without activating and logged SetWindowPos calls - the only calls are performed for CToolTipCtrl's window. So, no SetWindowPos for dialogs called. No BringToTop() called as well.
Solution
I've changed tooltip's parent window from dialog's grid to dialog itself - and that fixed problem. However, I still have no idea what was happened and why changing parent attribute matters.
Question
Could anyone give me a hint about what I'm missing? Maybe, tooltip causes repaint of grid, and that repaint has a bug causing repaint over active window, but I haven't found any proofs yet.
Haven't found something specific about tooltip's parent property in MSDN as well. Maybe, I have to read somenting about Windows GDI?

How To Change Panel/view in the Windows Client Area in MFC

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.

Use dialog controls without stealing focus

I have a modeless CDialog that contains controls, some CButtons and a CScrollbar. The CDialog is parented off of an edit box that I want to keep focus at all times. The problem is that whenever the user uses the controls, clicking a button or on the scrollbar, the control steals focus from the edit box, causing both the parent window to draw without focus (grayed-out header bar), and causing the control to take all the keyboard input. Is there a way for the controls to respond to mouse actions but not steal focus?
The controls and the dialog are all created with WS_CHILD. The controls are parented off the dialog, and the dialog is parented off of the edit box.
I've tried setting focus back after the controls are used, but that causes the parent window to flicker as it loses and then regains focus. Basically I want something that works like a combo box, where the scroll bar can be clicked or dragged around, but keyboard input still goes to the dialog itself, not just the scroll bar, and the whole thing never loses focus.
I haven't done anything like this for a long time, so I'm sure there are a million little details, but I think the starting point is to override the handling of WM_MOUSEACTIVATE.
I am a little confused about child-parent relationship you described.
Can you explain what do you mean by:
The CDialog is parented off of an edit box that I want to keep focus at all times
Any window hosting other windows inside of the client area is a parent of those windows. It is impossible to create window without WS_CHILD that is contained by other window.
Therefore all dialog’s controls are children of this dialog. It is also possible that child window hosts another child window.
CDialog is just an MFC representation of a dialog window; the same applies to other controls. For example CButton is an MFC class that wraps handle of the window’s window that is predefined as window button control.
Dialog never has focus unless is empty (does not have any controls). If dialog contains even one control, this control always has focus.
What focus means is that any given window receives mouse and keyboard messages. Only one control can have focus at any given time. In order for scroll bar to process mouse click or keyboard to move slider, scroll bar must have focus; therefore some other control must give it up.
Combo box drop box (I think this is what you are referring to) is not a child of the dialog. It is a popup window that for the duration has keyboard focus and captures mouse. When it drops down, dialog is deactivated and once dropdown hides, dialog state is changed back to active hence focus never changes, it returns to the control that had focus when dialog was deactivated.
What you are trying to do is probably possible but it would require a lot of coding. Probably hooking messages would do the job but I think it would be going against the stream.

Moving layered windows concurrently in win32

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.

Insert an UI into another MFC Dialog

I have one MFC application (exe) that contains two panes in its main UI. This application loads another DLL that also contains one dialog. How can I programatically place a Dialog defined into the DLL, and put it into (within) the pane of the MFC application? The question is not how to programatically retrieve the dialog from the DLL but how to put this dialog 'on the top' (within, inside) of one UI pane that belongs to the application?
My goal is to customize the UI of the application with dialog(s) retrieved from a dll and give the user the feeling that these dialogs all belong to one application UI. Thanks for any hint.
I have some applications with this feature, often with a tab control to alternate between windows.
First I set a frame in the container window, invisible to the user. The frame is just a placeholder to where the dialog window will be.
Then I make an instance of the dialog window as a global variable in the container class, I create the dialog window as a modeless window (using Create(), not DoModal()), move the window to the same RECT of the frame control, and call ShowWindow() to show the window.
Am I understanding you correctly that you don't want the dialogs to appear as dialogs, but rather as content of another window, or as a pane?
In other words, you want to get rid of the dialog's title bar and embed the dialog's content into another window, is that right?
That is possible. You would need to create the dialog without the title bar (change the window style) and make sure that you create the dialog's window as a childwindow of the window where you want the content to go. I can explain this further but I first would like to know if I'm understanding you correctly.