Create View if not visible

Topics: Prism v4 - WPF 4
Feb 3, 2012 at 2:26 PM


I am trying to create some behaviour similar to VS2010 solution window, Immediate, Output windows etc

where when you click on the menu or toolbar button, the window is made visible if it's not already visible !


Is there code already in prism to check if a certain view is visible ?

Feb 3, 2012 at 5:47 PM

From your explanation that's not exactly a prism thing but more a XAML thing. UI Elements have a Visibility property you can check

My suggestion is to use MVVM design, have your ViewModel contain a property called MenuXYZ_Visiblity and bind the canvas, stackpanel, grid section's visibility to that property.
Then using either commands or Event aggregator, if another viewmodel is calling it, have the Visibility be set from "Collapsed" to "Visible".

If what you want is things like a taskbar menu type of view to pop up what you want is a dock panel.

Feb 3, 2012 at 6:39 PM

That would work but require a change to all viewmodel and require tracking and maintaining state which is only referenced if/when the view_xyz cmd is exec

I was hoping there is a way to query the list of views and find out if the matching view is currently visible


Feb 7, 2012 at 8:57 PM

Well look more into the Event Aggregator, what it allows you todo is have say, every viewmodel Subscribe() to an Event, and when that Event is Published() a message will be sent to every subscribed viewmodel.

So I'm going to assume on your button your using a command in BtnViewModel

BtnViewModel contains a command that publishs the event BtnClicked
ShellViewModel & Module1ViewModel both are subscribed to the BtnClicked

When that command does its publish(), both viewmodels get a notification of it happened.


SO for your case, have your menu button fire the event HelpMenuOpened(), and then have your HelpMenuViewModel catch that event and set the HelpView's Visilbity property to true.

Feb 11, 2012 at 4:16 PM

For this conversation we have to define a few assumptions: 1) You are using some MVVM variation so that the View itself is cleanly separated from the ViewModel implementation. 2) The work your user is doing in within a main View (that has its own ViewModel) that contains ContentControls as placeholders for the dynamic Views that your are describing. 3) The way you animate, show, hide and so forth are beyond the scope of this post.

Take your Output Window for Example:

The ViewModel that is providing the DataContext for the main View that your user is doing their work from has a public property defined as follows:

public UIElement OutputPlaceHolder {get; private set;} 

The main View as we describe above that is holding the ContentControl that is to be your OutputView is defined in xaml as follows:

<ContentControl Content="{Binding OutputPlaceHolder}" />

When the user raises an ICommand from your main View where the user is doing their work, the ViewModel as referenced above contain code like this to set the UIElement to your View, since it is bound to the ContentControl your View will be shown instantly.

* Note regarding the following code: UC = IUnityContainer *

cmdShowOutPutView = new DelegateCommand(()=>{

OutputPlaceHolder = UC.Resolve<OutputView>(); ** Setting the UIElement property to an instance of your View object **


The OutputView has its DataContext set to {Binding} which rolls up to the main ViewModel that is providing the DataContext from your main View as described above. One technique is to record your Output messages on the main ViewModel in a data structure that you will need to define to represent your data, but the point is that it persists on the ViewModel that belongs to your main View where your user is doing work. The Output window View can then be added, removed or whatever.... It does not matter, because it just shows bound data from the main ViewModel of its parent View. 

Note: There are other more sophisticated techniques that we could discuss, but this example illustrates the concepts required to take things further. So based on the complexity of these dynamically added/removed Views this is what I would suggest. As a next step/future effort look into registering other objects within unity in combination with Dependency Injection as this allows you to cleanly arrange just about anything.



Feb 11, 2012 at 4:59 PM

Quick follow up here... You could consider a more global approach where you define your View that is to be your OutputView, you then define its ViewModel that contains the appropriate data structures to represent your data. You then wire the Constructor of your View.cs code behind as follows (Dependency Injection):

public OutputView  (OutputViewModel VM){

this.DataContext = VM;


Now your are setup for Unity to automatically provide your ViewModel when your View is constructed via Unity.Resolve<...>.

Next, register your View as a singleton with Unity as follows (again, assume UC = IUnityContainer):

UC.RegisterType<OutputView>(new ContainerControllerLifetime);


Now Unity will persist a single View & ViewModel via DI within you container.

For the Output data messaging, define a Prism event that your OutputViewModel subscribes to as this event will contain a payload of whatever data you want to track/show in your OutputView, as it will persist within your OutputViewModel in a collection or other appropriate data structure that you define.

Now, at anytime & anywhere in your application you can publish your Prism event with the payload of our output message/data. It does not matter if your View is shown or not b/c it lives within Unity and is listening and recording this information at all times.... Now, at anytime you can set your View to any container as follows:

 UC.Resolve<OutputView>() *This gives you your View Object to then insert into a Region or ContentControl*


This View/ViewModel combination are always alive within Unity, subscribing and tracking your output messages. Showing it within any container, be it Regions or be it direct Binding as described in the above/previous post... does not matter, as that is completely your option... Now, this is a singleton approach, having it persist within Unity may or may not meet your needs. Of course you can scope the lifetime of this object using this technique, but this leads us into an endless combination of possible solutions due to the flexibility and versatility of Unity & Prism... Have fun!