I have WPF app with ribbon control on top. I am new to Prism, and
I wonder what do you think about regions. Should I have just two regions,
one for the ribbon part on top and another region for the rest. It will be simple app
wtih ribbon on top and more views in the rest area.
You should determine the regions based on the layout of your application.
If your application has ribbon and a main content area, and your main content needs to change while the ribbon stays the same or the ribbon changes when the main content changes. then having 2 regions sound smart to me
Prism region navigation is done through the INavigationAware interface which lets you control the navigation to/from a certain view.
Changes are sometimes inevitable, but they might affect your INavigationAware implementation. So to avoid changes of your logic, it's best to first design the layout as detailed as you can.
Also, Don't confuse between regions and views. You can have 1 main content region in your main view, and multiple views to display your content in varies layouts. that doesn't require additional regions.
Think of all your test cases and see if you can implement all of them with two regions.
Good luck
Related
I'm developing a WPF based MVVM application and have a question relating to the best way of approaching view navigation within my application. Specifically, I am interested in the cleanest way to approach this navigation when I have multiple views that can cause navigation.
Let me summarize my current application layout so that I can better explain the problem.
The diagram above shows the rough layout of my main shell. The Main Navigation area is static and provides a number of buttons. Buttons exists for primary application functions such as Status, Configuration, Diagnostics etc. When one of these buttons is pressed, the content of the Contextual Navigation area is set. Specifically, this achieved by having the contextual navigation area contain a content control with the Content property bound to a single property of type ViewModelBase. In addition, the view models and views are tied together with data templates in the application resources.
The specific view/viewmodel populated in the contextual navigation content control then provides addition navigation options that are relevant to the primary function selected in the main navigation. When an option is selected in the contextual navigation, the main content region is updated in exactly the same way as described with the contextual navigation previously.
So I suppose you could describe the combination of MainNavigation and ContextualNavigation areas something very similar to an Outlook Style menu bar. i.e. primary selection at the bottom, secondary selection at the top, resulting in a change in main content area.
Now to the problem. I can make this work, but it's starting to get very messy! I've got the MainNavigationViewModel causing navigation, and multiple contextual ViewModels that get populated in to the ContextualNavigation area causing navigation. On some occasions, it may be that an action in the main content area also creates the need for navigation also. I've also actually got a Ribbon control that may also cause some navigation. So I've got navigation everywhere spread throughout my ViewModels and I don't believe that it is maintainable. PS. In case you were wondering, I'm currently using a messenger system to allow decoupled communication between view models.
I'm starting to think the best approach is to create an abstract service that takes care of navigation for all the view models within my application but not sure what that would look like. Am I on the right lines here and if so, does anyone have any suggestions for an application wide navigation service that handles navigations from multiple view models?
first of all what MVVM approaches are you using? View first or View Model first?
the right choice can make you life easier.
The idea you already have go's into the right direction Interfaces and inheritance - abstracting the navigation layer.
if you already use Messanger it's actually follows a similar approaches.
in your case an architecture plan would be more than necessary, take yourself time and draw it down.
I have a WPF application running on Windows 8. It is the one-window application that has three different views in the whole client area of the main window: live video from a webcam, help screen, and resource usage status. As you can see they are not related or interact each other, but I want to show them in one window rather than poping up a new window. The views will be switched by clicking a button in each view or by typing a keyboard shortcut.
I'm currently implementing each view using UserControl, and then adding/removing those UserControls in the grid of MainWindow on user events. I'm not sure if using the UserControl is the right direction because UserControl brings up the image of small widgets like buttons rather than a whole window content to me.
Am I doing correctly? I just looked at the Page control, but I'm not sure if it is a good idea. Thanks in advance!
I'm currently implementing each view using UserControl, and then adding/removing those UserControls in the grid of MainWindow on user events. I'm not sure if using the UserControl is the right direction because UserControl brings up the image of small widgets like buttons rather than a whole window content to me.
There is nothing wrong with a UserControl providing the bulk (or all) of the content for a Window. In fact, this is fairly common when using frameworks, as the Window is created for you in some frameworks.
I would not worry about using a UserControl for this.
Another popular way to implement multiple views on a single WPF window is to use a Tab Control and have each tab set to different user controls.
User Controls are definitely useful, and you have done something perfectly valid.
I have a winforms tab control which has several tab pages. Within each tab page controls (textboxes, radio buttons, etc...) are group into groupboxes. These group boxes are arranged from top to bottom but in some occassions some groupboxes needs to be visible and other ones to be hidden. Also control within each group box sometimes (depending on the scenario) needs to be visible and sometimes hidden. So I would like to know if someone knows a good approach to do this, maybe some kind of pattern if any. Also it would be good to implement a generic solution to do this. Could any expert in GUI guide me in the right direction to do this?
Using C# and dot NET Framework 4.0, WinForms. This is a desktop application, not Web-based.
You can define the scenarios in a class then add another class that will manage the layout by reading the scenario and laying the elements based on the scenario. I have not provided details because it varies on how specific you want to be and what behavior you want to achieve. It is better to put the Widgets inside a User Control and let that user control communicate with the layout manager.You can use the Mediator pattern or variation of it to coordinate between the widgets. Hope this helps.
I usually try to group related controls into UserControls (even if this means doubling up on some controls) and adding them to or removing them from the form as needed. An example of this could be payment methods - when the user selects a specific payment method (Credit Card, Cash, Cheque, etc) a UserControl with the correct elements is displayed within a panel on the form.
A good pattern to use when managing this sort of set up is Model-View-Presenter, in the example, all the UserControls would probably implement an IPaymentMethod view interface and provide a way to update the corresponding models.
Designing a presentation type application which consists of 2 forms, the first form will be used to control the presentation so it can be manipulated on the fly, it will be based off the first monitor of the pc, the second form will be on the second monitor (or projector). I need to update the second form with numbers and pictures during the presentation. In terms of accessing information between forms, would MVC be the best way to do this?
http://www.c-sharpcorner.com/UploadFile/rmcochran/MVC_intro12122005162329PM/MVC_intro.aspx
Cheers!
You don't make it 100% clear if you're are using Forms or WPF (you've put both tags) if you are using WPF the most popular and comfortable design pattern for is generally the Model-View-ViewModel (MVVM) pattern. Is this is quite close to MVC but slightly different. You can read about it here
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
In your application it would mean having data classes that described and manipulated the presentation itself (the model).
Then you would have a view model class (or group of classes) that describe what's visible in each window and the current state of the controls and the currently displayed slide etc. both sets of view models bind to and update the same underlying presentation model.
Finally the XAML and controls render two a 'views' one for each window, the views then become nice and clean binding only to the current state of the ViewModel.
Hope this general outline provides helpful inspiration, if you want and more specific info or advice please ask.
Mark
User Controls -- Do they serve a special purpose?
As far as I can tell they are no different to forms - they have the same toolbox and features.
Are there certain times when they are appropriate to use over forms?
It would be interesting to understand what they are good for.
You use them to group a set of controls and behaviors together in a re-usable way. You can't show a control on the screen unless it's added to a form somewhere.
One good example is a textbox. It's very common to have a label next to your textboxes. You can build a user control to make this easier. Just drop a label and a textbox on the control, expose whatever your properties you want, setup the new control in your toolbox, and now you can just drop this control on your form instead of needing to arrange a label and a toolbox on the form separately.
You could kind of think of them as a panel which "remembers" what controls you put on it. And there's one more important piece. You can put code in these controls as well, and use that to also build special behaviors into your custom controls.
I have to disagree (slightly) with the selected answer. Reusability is only part of what a UserControl is for.
All Controls are reusable. Almost all controls are reusable on the same Form/Window/Panel/etc. For example, a TextBox is a control.
There are two ways to create your own reusable control:
Custom Control
Completely custom, and reusable.
Created entirely in code.
You get a bit more granular control over what your control is doing this way.
Lighter weight (usually), because there isn't anything added in for designability within Visual Studio.
In ASP.Net only: No "HTML" type file to use or edit.
User Control
Completely custom, and reusable.
Created partially in a designer in Visual Studio, and partially in code. (via code behind)
Much easier to deal with from a visual aspect.
A little heavier, as there is pre-existing code added in by the framework to support designing inside Visual Studio.
In ASP.Net only: You can change the appearance a bit simply by editing the .ascx file (basically HTML).
User Controls serve the purpose of reusing controls.
Imagine you need a search box in several pages of your application. You can create a search user control and drop it in every page where you want it visible.
So, it's nothing more than a container that aggregates reusable blocks for your pages.
Forms have a lot of extra furniture that you don't need if you simply want a collection of controls together - the minimize and maximize buttons for example. If you just simply grouped your controls in a Panel, you'd have all the event handlers on the same form as the panel - with a user control, the event handling code is in the user control class, not the form class.
You can reuse the same control on many forms. In fact all items you are using while creating windows forms are the controls. User controls are just extra controls extending controls library provided by .NET.
In ASP.NET, user controls enable you to split your page into reusable components. For example, you may want to have a search box which can be used in different places on your website, so you'd use a user control. They can also be used for partial page caching. You can cache portions of your page to improve performance.