Application with more than one Shell or Popup Windows with regions inside it

Topics: Prism v4 - WPF 4
May 10, 2013 at 11:01 PM
Edited May 10, 2013 at 11:05 PM
Hi,

I am developing an Application for users that have more than one monitor and it is very important that he could move and maintain different Views in both monitors.

How can I do this. I suppose the solution is to instantiate a Popup Window that would have Regions and in that regions inject my Views.

I am starting with Prism and I would like to know the better solution. Will the Region Manager have control and monitor regions in the Popup window ?

What could be the better solution ?

Thanks in advance
May 13, 2013 at 3:51 PM
Hi,

I believe you could find the following blog post from Damian Schenkelman, which explains how to create a multi-shell application in Prism v2, interesting. Since the sample is made in Prism v2, you will need to adapt it to Prism v4, which probably won't give you major problems.

Regards,

Federico Martinez
http://blogs.southworks.net/fmartinez
May 13, 2013 at 4:59 PM
Thanks Frederico, I will check it out.
May 15, 2013 at 3:49 PM
Perfect. Thank you very much
May 16, 2013 at 6:48 PM
Edited May 16, 2013 at 6:57 PM
Just another point.

Damian article creates the Shell on the CreateShell of the Bootstrapper. I Will need to create the Shell on Demand, probably asnwering to a DelegateCommand, from a button or Menu.

The new Shell will be hosted in a PopUpWindow, that will be dragged to the other monitor area. I have found some post that talk about child windows. As you can see this window will not a be child window this window will be displayed in an independent mode. Without any visual hierarchy with the window that showed it.

How can I do this ? I presume I can create another window, and in the constructor set the Region manager like this:
  • RegionManager.SetRegionManager(shell2, container.Resolve<IRegionManager>());
But how will I have access to RegionManager, EventAggregator and every Prism Manager.

Thanks in advance
May 16, 2013 at 6:53 PM
I have an IDialogService that is responsible for showing my dialogs/popups. The implementation of the service creates a scoped region and uses the RequestNavigate method to navigate to the view in the dialog/popup. Very simple. Keep in mind, that your ViewModel should never declare or initialize a dialog or view directly. So in your DelegateCommand you would call _dialogService.Show(string viewURI) or something similar.
May 16, 2013 at 7:24 PM
Brian,

What I really need is to open another "main" window. The user can start a command and open as many Windows/Shells he wants, and show whaterver views he wants in the shells. The user will be able to open the same view in more that one Windows/Shells. I intend to use the KeepAlive = false for the ViewModels.

The new Windows/Shells wil be exactly like the main Shell, the only difference is that the user may ask for a new Sheel on demand.

I would like create dinamycally ContentControls in the Shells and inject the Views in these controls. The User will be able to adjust the window the appearence and position of these ContentControls/Regions as he wants, creating there own Dashboards.

I presume that the best way is to use the Same RegionManager for all Shells. The problem here is the RegionNames, they will have to be different in the created Shells. Do you think it is better use the same RegionManager for all Shells ?

Can I have access to your service, or could you post some code to help.

By the way your course in PluralSight is excelent I am just starting the View-Based Navigation
Developer
May 17, 2013 at 7:00 PM
Hi,

Based on my understanding, you should be able to create a new Shell in your application at any time by following the same steps that the bootstrapper does to create the main Shell:
  1. Create a Shell instance using the container.
  2. Set the corresponding RegionManager using the SetRegionManager method.
  3. Invoke the UpdateRegions method to register the regions in the RegionManager.
Brian has made a good remark in pointing that your view model should not create a Shell (or any other view) directly. Therefore, you could define a simple service that could be consumed by the view models and that would execute the aforementioned steps to create the Shell. It could also contain any logic to manage those windows, if needed. Besides the RegionManager, the rest of the services provided by Prism, such as the EventAggregator or the ModuleManager, are independent of the UI / Regions of the application, so you should be able to use them in all the windows without problems.

Regarding the regions of the secondary Shells, if your application will have several windows or will reuse views in different Shells, then I believe it could be appropriate to use an scoped RegionManager for each Shell to avoid conflicts between region names (you can obtain a new RegionManager using the CreateRegionManager method.) Take into account that the container only has the RegionManager of the main Shell registered; therefore, you will need to manage the access to the scoped RegionManagers of the secondary windows.

Also, in order to access the appropriate RegionManager for a view depending on the Shell it's being shown on, you might find the RegionManagerAwareBehavior described in the following blog post useful:
I hope this helps,

Damian Cherubini
http://blogs.southworks.net/dcherubini
May 18, 2013 at 12:52 PM
Damian,

As I told you I am using PRISM for the first time and I have a lot of questions. I have followed Brian Lagunas videos in Pluralsight and the IG Outlook sample.

What is making me a little concerned, among other things, is about Custom Region Adapters. I have followed the IG Outlook example and I have tried to inject some WPF standard controls in the ContentRegion, like DataGrid, DocumentViewer and the application crashed, and I presume that's because of the RegionAdapters.

My application is a Finance application with a lot of forms and different controls. How can I solve this kind of problem ?

Thanks
Developer
May 20, 2013 at 9:17 PM
Hi,

As far as I know, I believe that a RegionAdapter should not have affect over controls injected into the region, but over the control that is being used as a region; although this could differ depending on the implementation of the RegionAdapter.

If you are using a custom RegionAdapter that is causing problems it would be helpful if you could share it with us along with a description of what controls you want to adapt an how you want to use the region, so that we can help you with it.

Regards,

Damian Cherubini
http://blogs.southworks.net/dcherubini
May 21, 2013 at 7:28 PM
I think I have solved the problem.

If I use a UserControl in a Region hosted by a ContentControl everything works. I do not need to create any additional Region Adapters for controls not supported. I can put every control I want in my UserControl and I suppose it will work. Maybe this is not the best solution but it I have tried a lot of different controls and it is working.

Thanks to all of you