What are the differences between FormView and Dialog in MFC? and can anyone suggest when to use FormView and when to use Dialog?
I have to respectfully disagree with posts above. There is no difference between CFormView and a dialog.
CFormView is a dialog created as modeless and hosted by the frame as a client, resized as frame resize.
It is created from dialog resource you have to supply, as any standalone dialog. All message handlers for dialog controls are the same.
CFormView Create member calls CreateDlg, passing dialog template loaded by the constructor.
CWnd CreateDialog, calls CreateDlgIndirect member that in turn calls CreateDialogIndirect API creating modeless dialog.
You can also embed modeless dialog inside another dialog and it is still a dialog.
A dialog application just shows a dialog (and whatever controls you put in the dialog, plus any other controls you pop up from it, etc.)
A FormView gives you a fairly normal application with a main menu and such -- but the view part can also hold controls.
You'd use a dialog if you just want a dialog, and a formview if you want (possibly multiple) views that can hold controls. Big difference is that making it a dialog changes the basic nature of the entire application, where a formview just changes one view -- you could (for example) also have other (non-form) views if you wanted.
someone_ smiley
To answer your question about dialog versus CFormView.
I rarely use dialog-based application; only in cases that require simple tasks without overhead of more complicated UI.
Most of programmers start with dialog based app and after getting into implementing some functionality, it usually turns that the application needs menu and a toolbar and status bar, data storing/handling object, command routing handling and so on.
I would suggest creating SDI application with non-resizable frame.
You will have a dialog look and all the functionality of the MFC application free. You do not have to use document support if you do not need one.
From the coders view point, FormView supports laying out of UI controls with dialog resource, in WYSIWYG way. So when making a view with a lots of controls FormView could be helpful.
Dialog is not a view. It is totally different. Dialogs are separate windows and normally presented in the modal event loop (or modelessly in special cases).
Related
I have an SDI Document/View MFC app the wizard created with several different windows (workspace, properties, view, output). My main view CMyView is derived from a CTabView.
I want to offer a "Close Tab" option via the toolbar, menus and context menus, but ON_UPDATE_COMMAND_UI from within CMyView is not called, my guess is it's probably going to whatever view is in a tab but there are several different types of views that can be opened in a tab so I want CMyView to handle it in one place.
To me, having it handled in the CTabView makes the most sense design wise, but maybe I'll have to do it in the mainframe and then call a method of the view to get the result. But I thought I'd check here with people with more experience using MFC. What is the best way to handle it?
I need to extend an existing MFC app with a UI that will end up very cluttered unless I use a tab control. However, the nature of the UI is that there are some controls that are global, and only some that can be localised to a particular tab.
The standard use of tab controls (CPropertySheet + CPropertyPage) more or less expects there only to be CPropertyPage instances (tabs) visible on the CPropertySheet object, and nothing else. There is a Microsoft Example Project that shows a single additional window painted outside the area occupied by the tab control... but it's not immediately clear how it is created/drawn/handled, and it is only one single additional window that generates few events (I guess it is painted, so there must be a WM_PAINT event handler lurking somewhere).
Is it possible to lay out a bunch of controls with the MS Dialog Editor, including a tab control, and create the CPropertySheet using that template, hook up event handlers in a nice way, etc... or some equivalent way of getting the MFC framework to do as much of the creating, drawing and event handling as possible when it comes to a situation like this?
Yes it is possible to create dialog templates and use them in a CPropertyPage.
Each CPropertyPage behaves nearly like a dialog and handles all events for the controls on it.
Also there are features like OnApply that help you to manage the data exchange between the controls and your internal storage.
The central CPropertySheet only creates the dialog that get active. So OnInintDialog for a page is called the first time when the page gets active.
In the MFC since 2010 are more possibilities than a CPropertySheet. You can create tabbed views, that again may be CFormViews. I don't like CDialog based applications so I would prefer a tabbed view in a standard frame with toolbar and menus if appropriate for the application. So another method to unclutter your UI is to choose the MDI interface with tabbed documents... but multiple documents maybe isn't what you want.
Here is a sample of an SDI application with multiple tabbed views.
Also Coeproject shows some more samples here and with splitters and tabs here.
There are at least three solutions paths:
Try to squeeze the situation into the CPropertySheet + CPropertyPage framework which does not naturally allow for additional dialog controls on the CPropertySheet object, and so you will get no framework support this
Place a tab control on an ordinary dialog, and then use the TCN_SELCHANGE messages to fire code that manually hides & shows individual dialog controls subject to the tab control (again no framework support, but this time "within" the tab control instead of outside it)
Follow Mark Ransom's observation that if you can embed one kind of CWnd-based control on a CPropertySheet then you can probably embed any such object, including a CDialog-based object that has been developed in the MFC Dialog Editor
All of these approaches are going to encounter challenges, and it will depend on the specifics of the situation as to which is better. But first you should really consider whether there is a cleaner UI design which would lend itself to a simpler solution.
In my specific case, I saw no cleaner design alternatives, and found it easiest to take the second approach. It left me with some reasonably simple calls to ShowWindow() to show/hide the controls inside the tab control.
I am maintaining I big and mature application, without background on MFC paradigm and layout. I have experience with Qt, OO designs and UI frameworks (I'm aware of each thread responsibility, event loops, event handling hierarchies, etc.
I'm stuck with a settings CDialog window losing focus constantly, while I'm trying to configure my application. I also have a file explorer dialog that behaves exactly the same way. Both are activated by DoModal calls.
I've read that this is probably because I have two modal dialogs competing for focus. How can I debug that? What function could I break on to get a helpful callstack, so I can find the offending code? Is there an MFC::focusWindow(WHND window) or something that I could intercept?
The problem according to your description is that you 'have two modal dialogs competing for focus'. This should normally not be possible because by definition a modal dialog takes over the application and does not return control to its launch point until the dialog is closed. Without knowing the architecture of the application, the simplest solution would be to make the settings dialog modeless (create it then call ShowWindow(SW_SHOW) instead of DoModal. This will allow the message loop to run for the other modal dialog but not take focus from your settings dialog unless it is doing it explicitly in its own methods.
Use Spy++ to spy the messages/events that occurring in the dialog.
You can use SetFocus function, please refer to
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646312%28v=vs.85%29.aspx
I have a document within MFC C++ application. I need to delete one the buttons from the particular CMFCToolbar within a code (not resources) completely, even preventing a user to restore the button via toolbar customization dialog. At this moment I use RemoveButton method of CMFCToolbar but it only makes the button invisible and it can be restored via toolbar customization dialog that is not an option for me at this time. I will be very glad if you suggest something that can help me there.
There are two internal lists in CMFCToolBar that are used to reset the Buttons upon customization.
They are named m_OrigButtons and m_OrigResetButtons.
You may need to derive your own class and delete the buttons with the specific IDs from there.
But better: Never to include such a button on the first time when the toolbar is created!
I have a strange error and spend hours in the debugger without finding a solution.
(But it helped me to fixed another error that you should never call EndDialog from a WM_KICKIDLE task).
My problem is that i have a main window and a modeless dialog window wich raises a modal subdialog window. When the subdialog window is closed. The modeless dialog window turns itself into a modal window. My code really does leave the modal loop. And if i close the now modal window it behaves like an invisble modal window is active, meaning no interaction is possible anymore.
When i only run a modal dialog on top of the main window it is closed fine.
BTW: The main window is not the one available view CWinApp::m_pMainWnd but a new create FrameWindow. I hide the p_MainWnd and use it as an invisible message only window. From some comments and my debugging session i found that the pMainWnd has some special meaning but i could figure what exactly it has to do with modal windows (there is an undocumented "CWinApp::DoEnableModeless" for example).
EDIT: I'm posting a WM_CLOSE to the dialog and then use EndDialog(0) from the OnClose() handler to exit the modal state. I also tried to use EndDialog(0) directly. There is no difference between this two methods.
When MFC creates a modal dialog, it makes it modal by disabling the windows above it. The code that reenables those windows occurs when the dialog ends normally with a call to EndDialog. If anything prevents that code from running, the other windows will be locked out.
Modeless dialogs are a different beast, and there's a note specifically in the EndDialog documentation warning you to use DestroyWindow instead.
Maybe this is justifiable but I have a question:
why are you using hidden window? Was it created as message only window (passing HWND_MESSAGE as a parent handle and Message as a class) or you just call it message only?
OK, a little more info about MFC and dialogs.
MFC does not use Windows modal dialog. It always creates modeless dialog; either Create or DoModal call in turn ::CreateDlgIndirect windows API.
Modeless dialof rely on the main window message dispatch, while modal calls RunModalLoop that is similar to MFC window message pupmp (not a message loop).
It runs in the main thread of execussion without freezing because it allows for idle processing (calls OnIdle).
How do you dismiss the modeless dialog? As Mark pointed you should use DestroyWindow.
As for m_pMainWnd, MFC framework uses it extensively to determine may things that control main window behavior. By changing it you may have created the behavior you experience.
Did you set the value to a newly created frame you treat as a main window?
What kind of MFC application is it? SDI or MDI?
Would it be possible to create test app to duplicate this behavior and post it somewhere for download?
By the way, you do not have to be concern about DoEnableModeless, since it does not do anything but calls hook (COleFrameHook type) that is spasly used, unless you are trying to implement some functionality using OLE or ActiveX or you are trying to marry MFC and .NET Windows Forms.
In conclusion if your (or third party code uses this hook, I would suggest checking the code in the COleFrameHook class.