I'm looking for a smooth method of managing toolbars (and menus) with mvvm in WPF.
Consider an UI with tabbed workspaces and heterogenous content (like Visual Studio). There the toolbars should be hidden or visible depending on the active tab. How would you design the view viewmodel for the toolbars?
I'd use a collection of toolbar-viewmodels and bind the ToolbarTray to it, but afaik that's not possible.
Any recommendations are apreciated.
Links to samples, best practice papers, etc. are welcome.
I had this same issue in one of my applications recently. I was using a Ribbon as my main toolbar, and based on what module was selected the buttons on the ribbon had to be hidden or shown. I came up with two different solutions... hopefully one will work for you.
The first solution would be to create a region in the shell of your application (it can be a Grid/Canvas/whatever) and dynamically load the desired toolbar into this region based on what tab the user clicks on. In other words, if you have 5 different tabs that require their own toolbar, create 5 UserControls that contain a toolbar and load the correct one into the region when the user clicks on the tab. Next you'll want to respond to the event of when the user clicks on a button on the toolbar. In my solution I used the Mediator approach to allow ViewModels to communicate with each other. It works, but I don't know that I would do it again that way... CAL is probably the better approach.
The other solution would be to create one toolbar with all of the required buttons and bind their visibility to the ViewModel. Based on the user's selection, set the visibility of the controls to whatever your requirements may be. Hopefully one of these solutions works for you.
by the way... what part of Germany are you from? I know a man with the last name of Stoll, so I wasn't sure if it was a common name or not...
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.
I'm writing a Windows application in WPF. I based my UI in a single menu and a tab control to display different documents or application forms. Since the menu as well as other things are fixed throughout the application, I need a way to display the contents of each TabItem. I have found two:
write a user control for each form, or
using a frame to display the content of each form.
The question
Is there any other single way for doing this. How do they compare in terms of clean code? I mean, in .net forms I only need load the form from the menu.
I know, I should go for any pattern like MVVM, but for this very first time I want to use the default approach.
I go with Frames and host Pages (not user controls). I like Pages over User Controls as the event model seems to have more hooks.
I'm about to change my application to include tool tips for all buttons, combo boxes, etc. I was wondering if there are any recommendations on doing this.
For every control I'd like the tooltip to show the control's name in bold, followed by the description. I want to keep the style separated from the control, so I can change the tooltip style globally.
What I would like to have, unless there's a better suggestion, is two additional fields per button/combobox/etc: 1-ToolTipName and 2-ToolTipDesc, both containing a string. How can I accomplish this (and is it even possible?).
If you want this to be separate from the style of the controls, and you want to specify multiple "properties" per control, then an attached property may be an option.
I would recommend looking into Behaviors from the Blend SDK. They would make this fairly easy (especially if you're using blend), as it would allow you to make a tooltip behavior that you could just drag onto your controls.
I recommend using ToolTips with all toolbar and iconic controls.
You need to guard against having ToolTips in places where it is obvious what is happening in the UI, or the ToolTip hides information from the user forcing a mouse move.
The Popup control in WPF might also offer you the UI presentation you are looking to show additional information.
Super ToolTips, as in Microsoft Office Ribbon, also offer the ability to present additional information to the user.
There are recommendations for using ToolTips and InfoTips in the Win 7 User Experience Interaction Guidelines (aka UX Guide).
I am working on a little WinForm app and have been trying to find the answers to a few questions i have without any luck. Im a ASP.NET developer so WinForms development is new to me.
Here is my main question:
How do I create a menu system that once selected the contents will render in the Main form of the selected item. If its a GridView I want to the GridView to render inside the main application so they can navigate away without having to deal with the modal popup. I do not want to popup forms unless i explicitly say so. I guess the equivalent to this would be using a Master page in ASP.NET.
Make sense?
The closest thing to Master pages in winforms would be MDI (multiple document interface), which is a hideous Windows 3.1-era abortion of a user interface. Why this option is even still around, and why anyone still uses it, is beyond me.
The second closest thing (and something more acceptable as a UI) is just to have one main form in your application, and implement the different pieces of functionality your app requires as separate user controls which are displayed on the form and hidden as the context requires.
A weirder method, but one that might also work for you, is to use forms inheritance - design one "master" form with the menus and controls that you want to always be present, and then have each form in your app inherit from that master form. This would not appear to the user to be much different from my second option above, so I wouldn't bother with it.
There really isn't anything similar to Master pages in WinForms.
The closest to what you want to use would be a TabControl selecting a different tab will display that tab over the other tabs. If you don't like the tab look you could extend the TabControl to not show the tabs or hack it together by placing the TabControl inside a panel just large enough to show the content but not the Tabs and change tabs programatically in your menu control.
I'm trying to decide whether I should create a simple StackPanel with Buttons on it, or whether I should use the WPF ToolBar class to contain these buttons (I am creating a simple toolbar).
What are the pros and cons to using WPF's built-in ToolBar control?
So far, these are the only advantages I have seen:
The ToolBars can collapse when necessary; additional items are available from a context drop down.
If the ToolBar is contained within a ToolBarTray, multiple ToolBars can be repositioned relative to each other.
Are the any other benefits to the WPF ToolBar? Neither of these apply to my simple toolbar.
Accessibility might be better with the WPF Toolbar, because it shows itself to Windows UI Automation as a toolbar with toolbar buttons, rather than some random controls. You never know who'll use your software.
Another very small advantage is that buttons in the ToolBar will be styled correctly, whereas the buttons in the StackPanel will take on their default look. Not insurmountable by any means, but a little annoyance none-the-less.
I would say use the Toolbar, because you never know when the next project will come along and need it. You also never know when this project may need it. I don't think there is any real drawback to using it over a StackPanel and the advantage you didn't mention is you'll have more experiance with a built in control for the next project.
On the other hand, I don't see any harm in doing it with the StackPanel, only that if you need to extend functionallity in the future, you'll have to do some rework.