Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In most of the multi-tasking CRM applications I've seen, MdiWindow is used to allow users to open multiple windows at the same time.

But MdiWindow doesn't seem to be commonly used in WPF. Looking through Codeplex, I only found one abandoned MdiWindow project.

In some of the WPF-based CRM applications I've seen, they create a dashboard and only let users work on one thing at a time.

What's the best way to handle multi-tasking in a WPF application? Is there a better alternative to MdiWindow in WPF?

share|improve this question
up vote 1 down vote accepted

Usually the design I use works like a TabControl: there is a navigation area and a Content area

I think it's because I don't like cluttering my workspace with many windows for the same application. I would rather have a single application instance containing everything I am working on.

I also find it makes managing Views and Dialogs much easier with the MVVM design pattern. I'll usually have a ShellViewModel containing the currently opened views, a list of available views, and the currently active view.

share|improve this answer
hmm I seen some design is like you said, they put a navigation area(an expander, menus) on the left, then right side is the content with a tab. Everytime they select something on the left will open new tab on the right side content. But couldn't user says is diffcult if they want to compares data? (i.e Check PersonA and PersonB their information detail.) – King Chan Feb 10 '12 at 18:07
@KingChan It depends on your application. Personally I have a much easier time comparing data on a single screen by positioning both copies in exactly the same spot and switching back and forth to see differences. Usually I'll do this by switching tabs containing the data if the application allows for it, or I'll open 2 copies of the app and flip back and forth between them. Sometimes I will also resize them so I can see both at once. None of those options are limited by this navigation style. – Rachel Feb 10 '12 at 18:25
After thinking long time.... 3 days? And example like this I think I will do like what you said. – King Chan Feb 13 '12 at 20:09

Your question, as I understand it, seems to be about GUI Design in general rather than WPF in particular.

For presenting secondary information, you have the options of:

0 - MDI Windows (allows the presentation and automatic organization of several windows simultaneously)

1 - Docked windows as in VS2010 (allows user to organize the workspace so that he/she can focus on the specific desired windows)

2 - Tabs as suggested by Rachel (this shows only part of the information and hides the rest)

3 - Wizards

4 - Accordion displays (somewhat rare but allows you expand only bands of interest)

There are 3rd party tools that provide all the above functions in slick ways.

Some of the key points to consider when selecting which interface is to think of this:

A - Does the user really need to see/interact with all this information together or at once? Remember that no one can type or look (actively) at 2 windows simultaneously. Your ystem should display necessary information for taking a business decision together in one display when possible. Other (secondary) information could be obtained via navigation to modal windows. Most people will not be able to look at 40 different fields on the screen to make a decision or take an action. You will usually find that in business applications, a process is composed of steps, and each step has its own data. You should be able to complete a business process without having to display many windows at the same time. You should evaluate navigation between windows as an alternative (as in (3)).

B - Is the information presented in each window independent of other open windows? If not, you will be heading for somewhat complex programming. To make all windows respond to a change in one window may be tricky. Be careful.

To summarize, your business process, required data volume, ease of use and ease of implementation should all be elements in your choice. For example, if changing information in 1 window causes other windows (or tabs) to change, your program could be complex and you probably want to avoid doing this.

share|improve this answer
Thanks for the choices, I agree this might be not WPF in particular. But because of the Rich UI support in WPF, I wonder if there is any better approach than the old WinForm UI design we have been using in the old days. – King Chan Feb 13 '12 at 19:44
@KingChan, thanks for your comment, I wanted to stress on the fact that the design is sometimes more important than technology. – NoChance Feb 14 '12 at 8:15
Yes, I agree with that. No matter what technology you use, if your application is not ease to use, people will have hard time learning it and more complain. – King Chan Feb 14 '12 at 15:08

Rather than re-inventing the wheel, you may want to look into using an MVVM framework, like Caliburn.Micro, that takes care of a lot of plumbing when creating a shell (or dashboard) style application:

enter image description here

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.