I've created a dialog service using interfaces to show custom dialog/confirmation boxes (I know that Prism comes with this ability but the dialog boxes don't appear to be customizable and don't match my layout/color scheme). The dialog service has a register function that registers the dialog view type with dialog viewmodel type in a dictionary. This is done so that a viewmodel can be passed in and in a loosely coupled fashion, an instance of the needed view can be created. The code looks like this:
private readonly IDialogService dialogService = new DialogService(Application.Current.MainWindow);
// Registers the confirmation window viewmodel with the confirmation window view
dialogService.Register<ConfirmationWindowViewModel, ConfirmationWindow>();
so my initial thought was to try to create this in the unity bootstrapper (because of the registration passing in views and viewmodels) but I can't seem to find a way to do that and pass in the dialog service.
I must note that the constructor for the main window viewmodel also injects the region manager and the event aggregator for Prism; I had tried creating an instance in the bootstrapper and registering the instance but the creation of the region manager vs the injection causes errors. If I declare and initialize the dialog service in the main window viewmodel it of course works but from my understanding of MVVM we don't want the viewmodels to have any knowledge of the views so I'm trying to find another way to do it, without breaking IoC for region manager and event aggregator.
I am new to MVVM and Prism/Unity so my grasp of these concepts isn't fully solidified yet.
I know that Prism comes with this ability but the dialog boxes don't appear to be customizable and don't match my layout/color scheme
You can create whatever you like as dialog, just derive from PopupWindowAction and override CreateWindow (and other methods as needed) to create the dialog you always wanted.
In case anyone sees this later and is curious, my end decision was to get rid of the 'Register' function altogether in favor of a solid convention instead.
Previously, I would use this function and kept a dictionary of all the registered views/viewmodels:
dialogService.Register<ConfirmationWindowViewModel, ConfirmationWindow>();
this would register take the and store them in the dictionary so I could later pass in a viewmodel and create an instance of the appropriate confirmation message view. Instead I removed all code regarding this part of the solution and replaced it with some reflection mixed in with naming conventions.
Step 1: Ensure all views are named with the suffix View at the end.
Step 2: Ensure all viewmodels are named with the suffix ViewModel at the end.
Step 3: Ensure these are all in appropriately named namespaces (views in views namespace and viewmodels in viewmodels namespace).
(most of this ^^ is done anyway)
Final Step: Replaced dictionary with this code:
var viewTypeName = viewModel.GetType().AssemblyQualifiedName.Replace("Model", "");
var viewType = Type.GetType(viewTypeName);
in the dialog interface. Now, no matter what viewmodel is passed in, it will pull the appropriate view with less code and no necessary linking as was done before.
Related
I see in many posts that communications between viewmodels should be done using a messenger bus.
What I wonder is, is it considered bad to simply execute a child vm method from the main vm?
Suppose having a view with a TabControl, where each TabItem is a child viewmodel.
When I close my application, I need to store my settings calling a SaveSettings() child vm method.
I need to know if it's a bad code, and in case why.
main view
-> closingEvent
-> call MainVM SaveAllSettings()
-> for (ChildVM childVM in allTabs)
--> childVM.SaveSettings() (public method)
If your objects are already coupled to each other, i.e. if a parent view model already has a strong reference a child view model, there is no need to use a messenger or an event aggregator to communicate between them. Then you can (or rather should) call any methods of the child directly.
There are certainly cases where these kind of parent/child relationsships exist and it's not necessarily a bad thing or a sign of poor design. It all depends on the relationsships of your objects really.
I am trying to program in MVVM and I have the following use case:
A TextBox's text is bound to a property in the VM
A Button is command bound to a relay command
When the user presses the Button, the web browser's Navigate(url) method is called with the URL being the text in the TextBox
Above is the use case I want to create, but 1 and 2 is possible using the MVVM design pattern, but I could not find an adequate way to invoke the browser's Navigate() method. First of all, is it possible to call a method of a control from VM (please let me know if there is a way)? And in the above use case, what would be the appropriate way to structure the program if it is not possible?
Thanks
You could do the following:
Add a property MyUrl to your ViewModel
Bind MyUrl to your WebBrower's Source property
Make sure the property implements INotifyPropertyChanged. Then your Xaml:
<WebBrowser Source="{Binding MyUrl}" />
What if you REALLY wanted to call a UI method from the ViewModel?
If you ever do run into a situation where you absolutely need to call a method on a UI control for instance, you can hook up events on the ViewModel and then your UI registers to this event and does something UI specific...
VM code...
//... some VM logic
EpicNavigateEvent(url) // raise event, allowing UI to handle how
In your code-behind on your view (this is the part where some MVVM purests freak), you could register the event:
myVm.Navigate += doSomeNavigation;
...
public void doSomeNavigation(string url)
{
// call Navigate
}
I've successfully used this approach for applications where we have a single ViewModel layer and multiple technologies hooked up the views (WinForms, WPF and Asp.Net).
If you're looking for something more elegant, have a look at the User Interaction Patterns on MSDN.
The concept is the same though: Call something on the VM and the View is handles it appropriately.
Common scenarios for this type of approach is want to show a message to the user from the VM. Your VM should raise an event saying: ShowMyMessage("You're awesome"), then your UI is notified and handles it: MessageBox.Show(msg) or whatever.
As long as you stick to there rules you should be golden:
ViewModels should NOT be concerned about UI code
Views must ONLY handle the presentation of the data provided by your ViewModels.
Don't overcomplicate it. KISS...
I have a WPF application that provides navigation between few pages. The MainWindow is the Window object contains a Frame object. I then have few Page objects. I need to implement a StatusBar where some text will be updated (in a TextBlock) based on what action user has taken on a particular page.
Should my StatusBar be declared in the MainWindow or there is any better place for it?
How I will be able to access that TextBlock in StatusBar from various Pages?
What usually works for me is either pub-sub or dependency injection:
At first you might give your statusbar its own viewmodel. This would be composed into the shell view of your application, probably your MainWindow. I usually have a shell viewmodel comprising a toolbar or ribbon, a statusbar and, taking the remaining space, an IShellContent container. So, to answer your first question, I would declare it in its own view, give it its own viewmodel and compose it into your MainWindow.
The second problem can be solved in different ways:
Either give your statusbar viewmodel an interface, e.g. IStatusBar, and configure your dependency injection container to bind the viewmodel as singleton. Every viewmodel that needs to output status messages could use it via constructor injection, like this:
public MyViewModel(IStatusBar statusBar)
{
this.statusBar = statusBar;
statusBar.ShowMessage("Creating new MyViewModel...");
}
Or you could use a message bus infrastructure that comes with many MVVM frameworks today. Your statusbar viewmodel would subscribe a StatusMessage, and whenever something needs to post a status message it would create a new StatusMessage and publish it, like this:
public MyViewModel(IMessageBus bus)
{
this.bus = bus;
bus.Publish(new StatusMessage("Text"));
}
I would go for the first solution (dependency injection) because it is easier testable.
I have more of an architectural question. I'm trying to implement MVP in C# as follows:
IView creates Presenter
IPresenter has a property IView which holds View, that is bound to it
View CAN be Form, but Presenter does not distinguish between Form and non-Form types, so View can be swapped and the solution is to be testable
What I sometimes need to do, is to open some other form. E.g., I have Browser view with DataGrid and when I double-click on a grid item or select something and click Edit button, Edit event is raised and Presenter acts.
Now, Presenter needs to open a Editor view, which is also a Form, but the problem is, presenter should not construct the Form itself, because then it is impossible to Mock the View.
I'm pretty struggling with the proper concept. My code looks something like this:
var editorView = new EditorForm();
editorView.Presenter.Entity = SelectedEntity;
editorView.ShowDialog(View as Form);
Under the hood, EditorForm constructor constructs the presenter and assigns this (View instance) to the presenter:
public EditorForm()
{
Presenter = new EditorPresenter(this);
InitializeComponents();
}
From the View perspective, I can swap it to MockView simply by implementing the Mock and then instantiating the same Presenter from MockView's constructor.
I was searching for some other Q&A here and over the web but did not find anything suitable.
Thank you for all your hints.
If I understand your conception,
I suggest you to project the Edit presentation issue according to MVP pattern as you did with main view.
So create IEditView and EditPresenter and finally in main presenter create instance of EditPresenter. Generally control the edit view through its presenter.
After some brainstorming with some friends, we came to the conclusion, the best way to handle the case of instantiating different set of Views for production (FormViews) and different set for testing (MockViews) is constructing them in some context - in my case, Spring context is an option.
So far, I consider this as an answer for the problem. If you have some more clever solution, please feel free to share!
We're using Castle Windsor and Prism 4 (Feb 2010). We're using the Windsor bootstrapper that makes Castle play nice with Prism that was released in the CompositeWPFContrib package.
I'm trying to define regions on my main Shell's XAML. If I define one region, like so:
<ContentControl prism:RegionManager.RegionName="{x:Static core:RegionNames.ToolBarRegion}"
DockPanel.Dock="Top"/>
And then do the following in one of my Modules Initialize method:
_regionManager.Regions[RegionNames.ToolBarRegion].Add(typeof(SomeView));
...life is good.
However, as soon as I add another region in the Shell's XAML:
<ContentControl prism:RegionManager.RegionName="{x:Static core:RegionNames.WorkspaceRegion}"
DockPanel.Dock="Bottom"/>
And then do:
_regionManager.Regions[RegionNames.WorkspaceRegion].Add(typeof(SomeOtherView));
...I get the error: "The region manager does not contain the ToolBarRegion region."
What gives? As soon as I comment out the second region it finds the first, when I add the second region back in it blows up, as if the RegionManager refuses to hold a collection of regions. It should be said that this is my first foray into both Castle Windsor and Prism, so it's not out of the realm of possibility that I'm missing something painfully obvious here. Any light that could be shed on this would be most helpful.
Are you sure it's DockPanel that you are adding your controls to? Maybe your container is a content control itself (kind of control that accepts only one child)?
Also, you could try register your region manager in the bootstrapper:
RegionManager.SetRegionManager(shell, this.Container.Resolve<IRegionManager>());
See the following questions:
Cannot find Region in RegionManager (using PRISM)
WPF, Prism v2, Region in a modal dialog, add region in code behind
EDIT
I looked at the sample solution (link in comments), and found out that your view injection code gets executed before main view is created. Your module initializers get called in StartRuntime->CreatePrismBootStrapper, and DisplayRootView (which creates your shell) is called later. Of course it can't find the region when the shell hasn't been created yet.
If all you want to register your subcontrols in module initialize code, view discovery is more suitable - it doesn't require your shell to be already created. View injection is better when you need to switch views based on user input (in this case making sure that containing control had been registered is up to you).
You have several options:
Use view discovery - as you did in the sample solution.
Create and register your Shell instance before loading your modules. base.DisplayRootView() should be able to find it in the container so It wouldn't create another. One way to do, but I'm not sure if best:
PrismBootstrapper.cs:
protected override DependencyObject CreateShell()
{
Thor.Application.Views.ShellView view = new Thor.Application.Views.ShellView();
_container.Register(Castle.MicroKernel.Registration.Component.For<Thor.Application.Views.ShellView>().Instance(view));
// _container.Resolve<Thor.Application.Views.ShellView>();
return view;
}
.3. CreatePrismBootstrapper() after base.DisplayRootView ? It doesn't work (NullPointerException on ServiceLocator and I'm not sure if it would make sense since I'm not really familiar with libraries used by you except Prism...
Hope this helps...