I want to design an application much like Visual studio where the toolbars are context sensitive to the workspace area and their are common toolbars which have context sensitive functionality like cut, copy, paste (for these I can have application commands), comment selected (custom commands).
I want to keep the workspace unaware of toolbar controls.
I tried using custom routed commands but it only works on parents in the visual tree (bubble routing strategy) however my toolbar and workspace are on the same level in the shell.
Are their specific patterns (I am sure there must be) for designing such an application in WPF?
I implemented a simple version of what you described, where a toolbar had options that were context sensitive and were simply shown or hidden. The application used the MVVM pattern, so my toolbar had a view model. I leverage the message bus (sometimes called event aggregator) to publish messages which the toolbar's view model could react to.
Related
I'm trying to build an app in winforms with something similiar to masterpages in asp.net - a menu on top and when choosing an option from the menu the entire screen on the bottom will change while the menu remains (there are 10-15 screens in the future app, some are quite similar, some are not).
What is the best way of doing this? Should I use different forms for each screen or use a panel or something else?
If I use a panel or something how do I manage to use the designer with so many panels taking space on the screen?
Try with the MDIParent Form's. View the Example
http://www.codeproject.com/Articles/12514/Multi-Document-Interface-MDI-tab-page-browsing-wit
If it is just keeping the same menu and opening/closing parts of the UI you could simply add and remove instances of usercontrols to the main form.
If you need more features such as docking (like Visual Studio) look at this
Another option is to use Form inheritance
Which one to select depends on what you want to reuse and the features you need.
One option would be to make your application an MDI window and then load entire forms, maximized, into the parent window.
Then, you would be able to treat each form as its own self-contained item, since it really would be exactly that.
Is it not an option for you to use WPF? A WPF browser application fits the paradigm you are describing quite well.
Do you know what is the difference between: User Control, Pages and Windows on WPF Browser Applications. I've found information related with this, but all the time are about WPF Desktop application.
Is it different for WPF Browser application?
I'm deploying an application but I don't know what is the best option for the Login section, the main section, the about section, etc.
Could someone explain me how can I use this tools in WPF Browser application?
Thanks in advance!
I use Pages in XBAPs the exact same way I would use a Window object in WPF. That is to say, rarely.
I usually have one Page/Window for my application and that is it. Switching the current view is usually done by switching a CurrentView property in my ApplicationViewModel, which changes what View is displayed in the main page.
I use UserControls when I want to create some kind of generic control, or for my Views. My Views can also be DataTemplates, and it is not uncommon for me to have a UserControl View that also has other Views in the UserControl.Resources (providing that all Views are related)
For example, I might have a UserControl called ProductsView which is the View that displays a list of Product objects, and the UserControl.Resources will contain a DataTemplate called ProductView which defines how WPF should display the ProductModel.
I will be starting a new project soon and am looking for some architectural advice from those of you who have experience with WPF, Prism, and MVVM.
The project will definitely be WPF and I will be implementing MVVM (I will likely use Josh Smith's MVVM Foundation as a starting point) in order to be able to benefit from the separation of UI/logic etc. I am not sure though if I would benefit from using Prism as well to structure my project.
Let me briefly describe the project. There will be a main "toolbar" that will display a number of widgets. Each widget displays some basic data related to its function and clicking the widget will open a new window that will display much more detailed data and contain a rich UI for viewing/editing the data.
Now, I was thinking that I can use Prism to frame the project but I have never used it before and am not sure if it is suitable for what I am trying to achieve. For example, would my "toolbar" be a shell that contains regions that each widget would populate? Would each new window that is displayed when a widget is clicked also be its own shell with its own region setup? If I can get the pattern down for the toolbar and one widget on the toolbar, I can replicate it for the rest of the widgets.
Aside from Prism, I have a question about how MVVM should be implemented for certain data editing windows. Let's say I have a chart that displays some data and the user is able to directly click/mouse move on the chart to edit the data that he sees. All of the data is in the model and the view model is making that data available to the view via binding. My question is where will the mouse click/move events, that are specific to the chart in that view, be written? We don't want much/anything in the view's code behind and we don't want to have UI event handlers in the view model so I am not sure how this type of scenario is handled. I know that commands are the likely answer here but the MVVM samples I have seen usually show sample commands for simple button clicks. Is the general idea the same?
So, if anyone has any suggestions on the above or any general tips on working with WPF and MVVM/Prism, please let me know.
Thank you.
There are a few questions in there so I will do my best at covering them all.
I worked on a project that had WPF, MVVM, and Prism along side other frameworks. The best advice is to understand the power and functionality of each before glueing it all together. You don't have to use all the features of Prism for it to be useful in this situation.
For Prism you can use...
Shell and bootstrapper to initialise the application and load modules from other assemblies.
Create and configure Unity for Dependency Injection. You can use other DI Containers. Here you can add global services each module will use.
Use of EventAggregator to notify differnent parts of the application, usually across modules and views
Regions for naming areas on the UI so modules can add a view to a particular location.
The above 4 don't all have to be used but can easily be integrated in a MVVM /WPF application.
For example, would my "toolbar" be a
shell that contains regions that each
widget would populate?
Here you can have a region you create (you can derive from Region) that will manage the buttons on the toolbar. (I have used a region with regards to a Ribbon). A service can be exposed via an interface that each module can supply the command/image (what ever you have) that when it is clicked will create a ViewModel. You can do this inside the module's Initialisation.
Would each new window that is
displayed when a widget is clicked
also be its own shell with its own
region setup?
If each button opens a brand new window I would suggest introducing a common controller class that will create a generic use window and attach a view model that your module creates. No real need to use regions in this case unless you are gluing different views to a application window that stays open longer than the life of the view itself. The window in basic form can simply be this...
<Window ...>
<ContentControl Content="{Binding}" />
</Window>
Where within your controller it can do this...
public void DisplayView(ViewModel vm)
{
var window = new MyWindow { DataContext = vm };
window.Show();
}
The controller can be used within your module directly of wrapped within a service... although for testabilty a service and interface would be best. Make sure you have merged your module resources with the Applicaiton.Resources and use DataTemplate's to link your view to the view model.
My question is where will the mouse
click/move events, that are specific
to the chart in that view, be written?
Don't be afraid of code behind but you can in this case use EventToCommand attached behaviour that will route to a command on your viewmodel. MVVMLight toolkit has this which you can reuse if you want.
DI is very powerful and I encourage using it even without Prism as constructing your view models will be easier.
HTH
I think Prism will work great for you.
->would my "toolbar" be a shell that contains regions that each widget would populate?
Put a single region with an ItemsControl in the Shell
Create modules for each widget
Keep adding the widget modules to the same itemscontrol shell region.
The biggest advantage with this is that if you add more modules you don't need to change anything.
->Would each new window that is displayed when a widget is clicked also be its own shell with its own region setup?
No, you can use a 'WindowRegionAdapter' in the shell to create views for your widgets in separate windows.
->where will the mouse click/move events, that are specific to the chart in that view, be written?
You can use attached behaviors to bind events in your view to commands in the ViewModel purely in XAML. Google 'Blend behaviors' or 'attached bahaviors' for how you could go about doing it. There is no need to write any code behind for this.
To be honest I am only trying to give you the keywords you'd want to search to get all the information you need.
I am working on a Visual studio like application i.e. have a toolbox, an editor and property grid similar to VS.
User can drag and drop the controls(custom and third party) to the editor window and perform operations like resize, move, align, group etc.; Properties of that control needs to be displayed in property grid and user can update them from there.
As per my current understanding I will have to extend the Canvas to create my own editor and and Interface for controls which it supports; Each supported control will have to implement this interface so that it can be placed in our editor.
Something similar to this - http://www.codeproject.com/KB/WPF/WPFDiagramDesigner_Part4.aspx
Looking forward for any kind of help, comment or links.
If WPF is a requirement, wait for the VS2010 release and use the Visual Studio Shell in either isolated mode or integrated mode. Otherwise you can use the Visual Studio 2008 Shell isolated or integrated.
You'll get the docking support, addin model, editors with highlight and much more almost for free that way.
Finally, I used the Diagram designer approch to build my application. Although, I had to create my custom property grid which was painful.
Recently I came across following post which suggests that .Net DesignSurface can be used for building this kind of application -
How to create an UI Designer utility?
I have been working on a generic framework Wide to create VS like applications.
Update: Here is the CodeProject article on how to use the framework.
Wide comes with two modules and various out of the box functions:
Core module (Required)
Used for customizable splash screen
Used for Menus (supports regular menus with icon, checkable menus)
Used for Toolbar (menu view model can be reused for toolbars)
Multiple toolbars can be added to the IDE (check demo)
Themes (VS2010, VS2012 Light theme and no theme)
ThemeManager to add/remove themes
Used for Statusbar (in development)
Open file service with participatory handlers (could be based on extension or even file contents)
Save and restore layout along with opening documents
Logger module (For the logging tool)
I'm trying to build a simple application to test the idea of having multiple forms in one application. For example, in Visual Studio, you have the IDE - design area, and on the right hand side, you have a form called Properties and Solution Explorer
When you click on something in the design area, i.e. Textbox, on the right hand side, the properties for that object selected automatically changes.
I do not want to add the PropertyGrid ontop of the same form where the objects are, it must be independant on its own.
My ultimate goal is to have a 3D viewer/WPF and on the right hand side, a form. When you click in the 3D viewer on a line, or point, the selected object's properties must be displayed in the PropertyGrid
Second to that, I want to be able to dock the forms, or reset to default layout.
Screesnhot:
(properties should be docked inside the main form - not like screenshot)
Example: http://dan.virgesystems.com/images/CPVimage.JPG (Dead Link)
If you decide to do it using WinForms, there's a good C# opensource library for VS-style docking: http://sourceforge.net/projects/dockpanelsuite/
Here's a screenshot of an application using it: http://wiki.openstreetmap.org/wiki/Image:Kosmos.2.0.png
Try encapsulating your viewer and form into user controls. You can use the splitter control or panels to layout the container form as you please. Communication between the user controls can be done through events or direct references.