I dont hope to get any answer but i will try to be clear.
I tried Caliburn Micro . At first it seemed fine and all i need. Some features yes but other not.
All i wanted is a single window with some views as usercontrols and multiple dialogs at each view. Using a conductor.OneActive i could achieve the first with little pain. However switching between views even looking the example was to cast Parent to Conductor and call a method there.
Even example of caliburn micro did casting like this. Calling .close(false) at screen was same as close(true) resulting in killing the view and recreating causing lag in lowest end atom pc.
So only solution was to cast to parent.
Dialogs
I tried tons of dialogs examples but non worked and made my life hard.
Messagebox etc were DEAD easy but in case you wanted multiple dialogs you were out of luck.
If you put code at close callback to open another dialog you got bonus stackoverflow exception as it gets confused.(Endless loop).
I could figure a good dialog that could cache the view and at the same time to display efficiently multiple dialogs.
Event Aggregrator
Also i cant figure out how on earth event aggregrator is suitable for switching views. In case you have multiple conductors it could be a hell to manage.
To show a dialog - as in Modal Dialog that blocks the view that showed it - you should be using IWindowManager.ShowDialog.
You should take a look at prism library http://compositewpf.codeplex.com/
see navigation chapter: http://msdn.microsoft.com/en-us/library/gg430861%28v=pandp.40%29.aspx
But I don't know how EventAggregator could help you to switch views… you could subscribe to received an event on a closingView but… …
You might want to take a look at Catel. It has a UIVisualizerService which allows you to show windows based on their view model.
It also has a ViewManager (IViewManager) which allows you to manage all views inside your whole application. Besides that, it also provides a ViewModelManager (IViewModelManager) which does the same for your view models. Best of all: you can find all views that are connected to a specific view model in your application to interact with that.
Related
I was wondering what is the most conventional way to navigate between two unrelated view models using Caliburn.Micro? Let's say there's a tree of view models in one part of the application: ParentViewModel->ChildVM1->ChildVM2 and etc. Additionally there's an OmniVM which should be able to navigate to any of the aforementioned view models. By "navigating" I mean locating the appropriate instance (the activation part is straightforward after that).
I don't want to involve any usage of IEventAggregator, nor Container.Resolve kind of stuff.
Thanks for the response
devdigital said it in the comment and i am going to say it here again and as Rob (the architect who wrote the framework) would say it, Architecture matters in the UI too. This means you should consider how your presentation layer is organized. In other words, are you going to have a tabbed interface where the main window would be a Caliburn.Micro Conductor and the tabs conducted Screens, or are you going to have a Visual Studio kind of UI that uses docking windows and tool bars, consider this type of thinking when building the UI. Now if you don't like architecture and you just want to design your GUI then i could tell you that Screen and Conductor are the most important classes to consider for navigation. I Strongly Advise you to read the Screens, Conductors and Compositions article if you haven't already done so, it will give you an idea of what i am talking about and a bunch of helpful thoughts.
Edit: For your specific situation and since you have this deeply nested structure i would create an interface for navigation on the MenuViewModel, something like this:
public interface IMenuNavigator {
void NavigateToItem(Item i);
}
Then i would inject this into those inner view models, i think you have a feeling of what i mean. On the other hand, you can also use the IEventAggregator which is used for loosely coupled communication between unrelated components (viewmodels) such as in your situation, so you publish messages on the aggregator for navigation and the MenuViewModel listens to those and handles them correctly. You may even come with a better idea depending on your specific internal situation. Hope that helps.
I am building a WPF application and using the MVVM for the first time. Overall using MVVM has been very interesting and one of the major benefits is the nice separation between the view and the model classes. It kind of disciplines (at least young developers) to not to mix them together.
We have a scenario where a window needs to be closed on a button click after a confirm message box. Now this can achieved the old-way by handling the button click event and closing the window in the Window class itself. Or we can do it MVVM way by creating a command in ViewModel, call Window to show message box..etc.
I understand what needs to done here, but my question is - is it necessary to use MVVM commands in all cases? Are there exceptions where we should not use commands e.g. simple UI actions? Are we not overusing MVVM here? What exactly will the benefits doing everything the MVVM-way?
Or we can do it MVVM way by creating a command in ViewModel, call Window to show message box..etc.
Let me pick this apart, mainly because IMVHO I see this done wrong all the time - a lot of people try to do too much in the VM. First of all, ask yourself the question:
Is the prompt related to the data or business rules in any way whatsoever?
If it isn't, i.e. it is simply a "are you really sure?" type prompt, then this SHOULD be done purely within the code behind of the view. The only time the viewmodel needs to have any knowledge or take any action is when it actually has something to do with the viewmodel, in which case you should expose a command from the VM, but the actual window closing is still done from the code behind of the view.
The VM should know nothing about the view that it is bound to, that is one of the purposes of the MVVM pattern. It can expose commands, but it shouldn't know that a user has interacted with a specific UI element1, and it shouldn't directly know that the window is about to be closed. It is okay for the VM to prompt (via a dialog service, which you do have, yeah?) that the current data is unsaved, but it doesn't know about the window in general because it doesn't know how its data is presented.
Sometimes you will walk a fine line, and it is easy to over analyze whether something should be done purely from the view, purely from the VM, or as a mixture of both. If you remember the role of the VM, and remember that it is okay to have code behind in the view (provided it is only doing view related stuff and handing VM stuff off to the VM) then 99% of the time you won't have a problem.
1 For example, the VM shouldn't know or care whether the user just clicked a button, hyperlink, or touched a hot spot in an image. The same command can be used to handle any of this.
I have built out a couple of keyboards for a touch aware app we are building in work. Since we use a controller that is aware of when the app is in touch screen mode I thought it would be nice if, in design mode, we could associate a control with a keyboard type and have the controller look after the calling of the keyboard.
One of the things I do not want to do is to sub class each type of control just to add this property as I feel it is a very heavy for small gain. I had thought of using the tag property but it is not available in all controls due to use.
I was wondering if there is a way of attaching a property to a control on design time for the purpose of adding this meta data. So to recap I would like to be able to give each control a value that would be read by the controller to decide what keyboard to show.
Yes, the designer supports this. Good examples of existing components that do this are ErrorProvider and HelpProvider. Note how they add properties to existing control types.
You'll want to implement your own component, it needs to implement the IExtenderProvider interface. The MSDN Library article for it has a good example that should help you getting it right.
I am trying to get into MVVM and away from the code behind approach in Silverlight, and I want to know the best practices around how to invoke view logic.
I have a very basic page where I have bound a listbox to a collection of domain objects, this is all using MVVM, so when I recieve my data back from the services, I want to fire off an animation and view changes on the screen.
Where/How is the best way to doing this? Silverlight (version 3, BTW) doesnt have triggers does it? I have seen blogs where people seem to be using them, but i think they must be rolling their own? Not sure... anyways, any thoughts ideas here is greatly appreciated
First of all, I think code behind is just fine as long as it only works with the view, i.e. it is concerned only with UI concerns. Don't struggle for no-code-behind when the easier way out is just as correct.
Secondly, of course sometime you need some sort of disconnected communication between your view and view-model (for example, getting multiple selected items from your view into your view-model). For these purposes you could use an aggregator like MVVMLight's Messenger, which is both simple and expresses the concept nicely. You can send a message from the view-model and have the view listen for it; also you can send messages from your view (when some events occur) and broadcast them.
MVVMLight also includes some utility classes which make it easy to bind events directly to Commands in your view-model, so that's the easier option in most cases I think.
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.