My application (C++, Visual Studio 2015) incorporates tab control. In most cases it behaves well.
Rarely, changing a tab results in corrupted interface.
Example:
Tab 1:
Tab 2:
Sometimes, when moving from Tab 1 to Tab 2 I get:
The arrow points on the problem area.
My code is very simple:
All tabs are implemented as dialog boxes
When the user click on a tab, all dialog boxes are hidden (ShowWindow)
Then the selected tad shows its dialog box.
This is cause by group box, it's background is not erased. Remove WS_CLIPCHILDREN flag from the parent of group box (child dialog or child window which owns the group box). Or subclass the group box control to paint its background.
Related
I have a win32 dialog with a text label, a user box (which is going to be filled a control thats created on the fly) and two pushbuttons. The user box has the focus set to begin with.
Now, in the initdialog, when I create a new control and add it to the userbox rect on the dialog, I actually want the focus to be on the control first and then go to the two buttons on tabbing and then back to the control. I tried using SetWindowPos(hWnd,HWND_TOP,0,0,0,0,SWP_NOSIZE | SWP_NOMOVE); to achieve this. But no help. I tried calling SetFocus() on the new control. The, the focus is set on the control on init, but when tab is pressed it goes on to the buttons and doesn't come back to the control. The focus just shifts between the two pushbuttons.
Any idea how I can add this newly created control to the tab order ?
I am developing a desktop app using MFC. The following image shows the current state of the app's window top part. The area marked in red is unnecessary and I want to remove it.
How can I remove that space or atleast change the color to match the rest of the window background?
More Info:
The App is using Ribbon UI. I have added the App button programmatically in onCreate of CMainFrame. Is it the bar that holds the Ribbon categories? I tried SetMenubarState(AFX_MVS_HIDDEN) thinking it was the menu bar, but that didn't work. Just changing its color is also acceptable.
Update:
I have managed to change the color of that ribbon strip, and removed the caption bar I used for showing the 'add' button. Now I need to figure out how to place the 'Add' button on the right side of the ribbon strip.
I'm wanting to make something like a tab control, but without visible tabs at the top.
I would prefer to have the tabs selected from a list or tree at the left hand side of the page, something like this...
Selecting the list/tree item at the left changes everything on the right-hand side of the dialog.
I know I could do this by individually showing/hiding all the fields on the RHS, depending on the selected view, but this is unmanageable to design, when there are at least 10 different designs. C++ doesn't let me design groups and make them visible/invisible in one go. I would prefer to design them as totally separate dialog resources, and then bring them in, like a tab control.
I believe Windows Forms has a ContentControl, which is like a tab control without the tabs, which sounds perfect, but MFC doesn't seem to have this.
Is there a way to do this nicely? Or maybe even a 3rd party control to handle it?
In MFC you would do this by making a child modeless dialog for each group. For each dialog turn off the titlebar style and border style and it will blend in to the parent window instead of looking like a dialog. Create all the dialogs, then use ShowWindow to show/hide one at a time.
Minor detail: Put an invisible control (like a group box) on the parent window to serve as a landmark. When you create each dialog use MoveWindow to position and size it on the landmark.
Use window style WS_EX_CONTROLPARENT in the parent window to help with tab key navigation from parent to child.
Yes you can using DIALOG resources. Set the DIALOG Style to Child, Border to None, Title Bar to False. You can then add implementation classes/files for each DIALOG. The dialogs are then inserted/removed to and fro the parent as a child components by setting the containing window as the dialog's parent (i.e., SetParent)
My application uses stacked dialogs to select between options in several places. For example, the dialog box below uses two stacked dialogs:
To choose between "shooting methods", the user selects from the drop-down list in the bottom right. This changes a child dialog box above it.
The "advanced options" box (located in the child dialog box) selects between a simplified interface and a more complete one.
In each case, the stacked dialog box is implemented using a picture object as a placeholder in the parent dialog. When a page is selected, SetWindowPos is called to move/resize the child dialog (pNewPage) to fit the placeholder.
// Show the newly selected page
pNewPage->ShowWindow (SW_SHOW) ;
pNewPage->SetFocus () ;
// Position the newly selected page
CRect rcDlgArea ;
GetDlgItem (IDC_DLG_AREA)->GetWindowRect (&rcDlgArea) ;
ScreenToClient (&rcDlgArea) ;
pNewPage->SetWindowPos (this,
rcDlgArea.left, rcDlgArea.top, rcDlgArea.Width (), rcDlgArea.Height (),
SWP_NOACTIVATE) ;
This has worked very well up until now, but one of my users in Germany is having a problem I can't explain. When he opens the tool, the stacked page comes up looking like this:
Note that the child dialogs are stretched so that the text in the child dialog appears larger than the text in the parent.
Other than the visual layout issues, the child dialog also seems to "cover" the selection drop-down in the bottom right (located in the parent dialog). Although the drop-down is still visible, CBN_SELCHANGE messages are not received when the drop-down list is clicked.
I am at a loss to explain why the child dialog boxes are being rescaled. As you can see above, I've tried to be very explicit about the resizing of the dialog box, but this doesn't seem to work.
Can anyone think of a reason why the child dialog might be rescaled on some systems but not on others? Any help would be greatly appreciated.
Thank you,
Michael
Seems like this user has larger fonts selected than what is used in the first screenshot. Note that dialog sizes are specified in DLU's, which scale with the size the user has selected for the font. You can either scale your dialog explicitly, in pixels (bad solution, this will make your app look even worse on some configurations), or do your calculations in DLU's everywhere. Your second screenshot also seems to show that the child dialogs use a different font than those of the wizard. I'm not sure why that is, I guess it's something in the window styles you pass to the wizard when you create it.
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.