I have created a MDI project with CView's using VS2008Pro.
I want to have some sort of bar at the bottom of every CView where i
can put controls on, like buttons. I dont know how this bar is called
and how to create one for every CView.
I have a picture of it here to explain what i want.
http://www.4shared.com/dir/32975742/b4bac91c/CView_Bar.html
Could someone please tell me what kind of bar this would be and how to
create it for CViews?
Thanks.
I think, what you want is basically a Toolbar (to answer your question how it is called) in an MDIChildWindow (similar like the toolbar in the main frame window of your application which is created usually by the MFC application wizard automatically). The way to add a toolbar in a child frame window is very analogous to what the wizard has added to the main frame window. You can decide in code where the toolbar shall be located (top, bottom, left, ...)
You can find a brief "How to..." here: http://support.microsoft.com/kb/155141
Also try to google by "Toolbar in MDIChildWindow" or similar. You'll find many resources, I believe.
Related
I need to add a clear button inside the CEdit control like this:
And I used CMFCEditBrowseCtrl, as described in this article:
MFC Feature Pack - CMFCEditBrowseCtrl.
But the problem is that it shows a very small icon on monitors with high pixel density:
I tried to set a big icon, but the button remains narrow:
Could you please advice some solution?
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 CFrameWndEx with several docked CDockablePanes but I can't seem to get notified when the size of the docked pane is changed (so I can resize my other windows accordingly). Tried Spy++ to check for messages, but custom draw seems to be the only one (which doesn't seem appropriate) and also tried overriding RecalcLayout, but that is not called under this circumstance. OnSize doesn't work because the size of the frame itself is not changed. Any ideas?
(Ps: I'm pretty sure it's possible because I used to have a splitter window as the 'client' area, and it would resize itself magically when the panes were resized)
OK this is a bit weird, but I had the exact same question, searched on Google, then saw that I had answered this question over a year ago but completely misunderstood what the question was about :)
Anyway for reference of future Google using people, the answer to this question is to override virtual void CFrameWndEx::EAdjustDockingLayout(HDWP hdwp) and do any resizing of client controls there. To get the client area after the hiding/closing/whatever of panes, use m_dockManager.GetClientAreaBounds(). My AdjustDockingLayout looks like this (m_View is the child window that is supposed to fill the whole client area regardless of the state of any docking panes, adjust as needed):
void CMainFrame::AdjustDockingLayout(HDWP hdwp)
{
CFrameWndEx::AdjustDockingLayout(hdwp);
if (m_View.GetSafeHwnd()) {
CRect rectUsable = m_dockManager.GetClientAreaBounds();
m_View.MoveWindow(rectUsable);
}
}
I think the issue is that the 'content' of the CFrameWndEx is itself a window, and in that window live the 'main content' windows. Check with Spy++ for the window hierarchy and if any of the child windows of the CFrameWndEx (other than the dockable panes) do get message when they are resized. Basically when docking panes are docked, the CFrameWndEx resizes its children, so you'd have to detect it there and (if required) reflect the message back to the CFrameWndEx if that's really where you need it.
Alternatively, maybe I'm misunderstanding and is what I described exactly what you're trying to do. In that case, I think there is something wrong with the way you add your window to the CFrameWndEx since that should handle the resizing itself. Is the parent of the child window set correctly to the CFrameWndEx when you create it?
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.
I'm trying to create a custom dropdown for a derivative of CComboBox. The dropdown will be a calendar control plus some 'hotspots', e.g.
So I figure the best way to achieve this is to have a simple CWnd-derived class which acts as the parent to the calendar control, and have it paint the hotspots itself.
The window needs to be a popup window - I think - rather than a child window so that it isn't clipped. But doing this causes the dialog (on which the combobox control is placed) to stop being the topmost (foreground?) window, leading to its frame being drawn differently:
alt text http://img693.imageshack.us/img693/3474/35148785.png
This spoils the illusion that the dropdown is part of the combobox since its acting more like a modal dialog at this point. Any suggestions on how I make the custom dropdown behave like the regular dropdown?
Are there any other pitfalls I need to watch out for, e.g. focus and mouse capture issues?
When you create your popup window, you need to specify its owner. Owned popup windows will activate their owner when you activate them. Not specifying an owner will cause your window to get activated, which causes the change in the owner you're seeing.
Yeah I had this problem once. A quick google makes me suspect I solved this by using CreateWindowEx() and specifying WS_EX_NOACTIVATE. I have some other code that achieves the same effect by making the window with WS_EX_TOOLWINDOW rather than as a popup window, but I'm not sure of why that was done that way, my intuition would say that making it a popup window would be the way to go.
You can find in the following links two sample project that put in the CComboBox dropdown window a CTreeCtrl or a CListCtrl controls ... similar, you can put whatever you need there. Here is the links:
Tree ComboBox Control
and
List ComboBox Control
I hope this help you.