How to choose, Dialog-based app, MDI app, or common window app?

[LifeIsSuffering]

I'm designing my app by using of MFC, I'm not quite familiar with MFC framework, my background is some Win32 and WinForms experience. Right here I got some designing issue, and I'm trying to get help from you guys, first here's how my app would look like,
1. Basically, there will be a main window, with some dynamically created sub-windows inside, which may have some nested, also dynamically created, child controls over there, too. Some of controls would be straight CWnd-derived, since I have to draw them by myself in most cases.
2. Sub windows are independent with each other, that is, they conform to standard window behavior, they accept input messages, they have z-orders, they have titlebars (in my test, creating a CWnd with/without WS_CAPTION got different behavior regarding to focus/input message).

At the beginning, I created a CDialog-based app, however, it worked wierd. The focus, the z-order, the painting, all of them got problems. I still can't fix it.

So, I'm rethinking if a CDialog-based app works for my use case. Frankly, I've never seen a dialog-based app contained windows. The reason why I didn't pick up MDI was that I'm totally new to it. I knew little about doc/view, and I did't think concept "doc" was good for my case, I might only need the "view". And people always said MDI got things more complicated.

Secondly, I'm also doubted that building my controls depends on CWnd. I thought it would be simple, when I need to draw then I draw it in OnPaint, when I need to respond specially then I handle messages in WndProc, world should be simple enough. But it doesn't look so simple now. WinForm get its base control type - UserControl, not does MFC.
I found that messages routing didn't work exactly as expected, so I sit back and rethink about if my orginal design is right.

What should be basic structure of my case?

Welcome any suggestion.

[VictorN]

1. Use MDI with Doc/View architecture.
2. If you are sure you don't need doc at all - just ignore its existence. Note, however, that if you needed to have more than one view then using doc/view with CDocument::UpdateAllViews method would make your life much more easier!
3. Start with the common controls. If you'll need something that cannot be achieved with them - (only then!) create your custom control. It will be much easier than draw all the controls yourself and then handle user interface with them.

[LifeIsSuffering]

1. Use MDI with Doc/View architecture.
2. If you are sure you don't need doc at all - just ignore its existence. Note, however, that if you needed to have more than one view then using doc/view with CDocument::UpdateAllViews method would make your life much more easier!
3. Start with the common controls. If you'll need something that cannot be achieved with them - (only then!) create your custom control. It will be much easier than draw all the controls yourself and then handle user interface with them.

Thanks a lot.
For item 3, sure, I won't make my wheels all from scratch. If I need a custom editbox, I could have CEdit-derived control, but if there's no appropriate common control, I have to build it from CWnd, right?

For dialog compared with MDI, I'm trying to confirm that if dialog really doesn't fit my case, since I found messaging routing was messed up, e.g., I had even to manually pass some messages from child to parent.

[VladimirF]

For dialog compared with MDI, I'm trying to confirm that if dialog really doesn't fit my case, since I found messaging routing was messed up, e.g., I had even to manually pass some messages from child to parent.

As soon as you hit first limitation of the dialog-based app – it’s time to switch to another type of app.
As Victor suggested, it is much easier NOT to use some extra features of the “rich” framework then to implement new features into a “poor” one.
And about documents – do you plan to save ANY data in your app? You might find out that documents are very handy…

[LifeIsSuffering]

And about documents – do you plan to save ANY data in your app? You might find out that documents are very handy…

Not yet. There would be an external data source which I could read, parse and generate views accordingly, but I don't need to save them. I'm sure that won't be single-doc/multi-views relationship.

Regarding to doc/view framework, I thought it's very applied to single-doc/multi-views in the past, sounds I'm limited.

I'll demo a MDI, thanks all you guys.

[JohnCz]

Well, my three pennies:

Dialogs are designed mainly to collect some information used by other parts of asn application.
If you need more forget dialog (as mentioned in earlier posts).

The only difference between MDI and SDI application is document instance usage. SDI application is using single document instance while MDI multiple document instances. I repeat: this is one and only difference.

In both type of an app you can have multiple views that are wired to the same document instance. In a frame (main or child), you can swap and show one view at the time or you can layout all views in some kind of pattern regardless of the application type or mix those two together.

Now, sine you have considered dialog based app I am not sure if MDI type of interface is what you are looking for.
It seems that SDI is more appropriate.

If you do not need document as MDI/SDI stipulates, to have it as central data repository, you can get rid of a document template and create only view(s) and a frame.

[LifeIsSuffering]

Well, my three pennies:

Dialogs are designed mainly to collect some information used by other parts of asn application.
If you need more forget dialog (as mentioned in earlier posts).

The only difference between MDI and SDI application is document instance usage. SDI application is using single document instance while MDI multiple document instances. I repeat: this is one and only difference.

In both type of an app you can have multiple views that are wired to the same document instance. In a frame (main or child), you can swap and show one view at the time or you can layout all views in some kind of pattern regardless of the application type or mix those two together.

Now, sine you have considered dialog based app I am not sure if MDI type of interface is what you are looking for.
It seems that SDI is more appropriate.

If you do not need document as MDI/SDI stipulates, to have it as central data repository, you can get rid of a document template and create only view(s) and a frame.

Thanks your lenthy reply.

Now I selected MDI architecture, since I do really need multiple frames, and further multiple views co-exsited under same frame (views coexist in some pattern). There's no doc in my design, so I built a MDI without doc/view support at all.

Here I got a new question, MDI window manages frames, and frame manages view, right? But I saw there's only one m_wndView member in parent Frame, so I guess MFC is just designed for one-one frame/view relationship. Because I got multiple views, I have to manage all views by myself in some way.

void CFrameWindow::OnSetFocus(CWnd* pOldWnd)
{
CMDIChildWnd::OnSetFocus(pOldWnd);
m_wndView.SetFocus();
}

BOOL CFrameWindow::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
// let the view have first crack at the command
if (m_wndView.OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;

// otherwise, do default handling
return CMDIChildWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
}

I believe the above code generated by MDI template proved that. Parent frame has to pass some kinds of msg to have child handle it first if required.

Originally I thought parent window would automatically manage children, but it looked like not exactly. If it's true, I'm concerning for what management should be done, some special msg routing? And what should I pay more attention to?

[JohnCz]

Everything depends on what do you need to show in your application.
Assuming that you are using document (and I think that would be desirable considering usage of multiple views and document delivered mechanism of updating all views when data changes.
MDI application will of course provide multiple frames but this is not what you want. Each frame will be created with different instance of the document and view according to a document template.

You can modify and display each view in different frame, all views wired to the same document instance. It may be tempting but it is confusing for user unless you clearly indicate somehow (title may not be the best indicator) that frames host view that belongs to the same document.

You can also create multiple views in the same frame and show it in layout maintained by a splitter. Just make sure they belong to the same document. You can make splitter panes sizes fixed. This approach seems to be most appropriate since splitter signify ability to resize panes and that also creates xonfusion.

I think the best approach would be to create frame and write a code to layout views without splitter.

Another option, if you want to display single set of views is to create SDI application. You have the same option for displaying views as stated above. The difference being that views are hosted in a main frame instead of child frame.

MFC does not limit number of views that can be created as children of any frame. It is just a matter of overriding default framework functionality.

You can do all of the above without a document if you desire.

[LifeIsSuffering]

Thanks JohnCz and all.

That's right, in any option, I should try further to manage all views, layout, msg handling, maybe still other things, override default framework functionality.

[JohnCz]

What Version of VS (if any) are you using?

[LifeIsSuffering]

What Version of VS (if any) are you using?

VC8. Any comment?

Sorry for so late reply. I already got a working MDI app. It works well so far.