WPF Context Sensitive Menu Ribbon - wpf

im a bit new to wpf.
im trying to make the acclaimed Ribbon the center for all menus and commands of my custom app
now my main window is a tabcontrol with a few major tabs: contacts, sales, appointments,expense etc.
on top of the tabcontrol is a ribbon
(pretty similar to MS Outlook)
for each tab i have different buttons that i need
(the tabs each display a different UserControl as its main content)
plus there are several buttons that should always be in the ribbon (settings, about, new appointment...)
the best would be if i can add the RibbonTabs directly in the usercontrols and somehow merge them auto-magically with the main ribbon at runtime depending on the visible tab
if thats not possible then there is something called ContextualTabGroups, but for the life of me cant find any info on how to bind/trigger the different ribbons to certain cirmcumstances/childcontrols or whatever.
if i need to call .visibilty upon load and close of each usercontrol, then theres nothing "contextual" about that
thank you very much

Related

Managing lots of controls in FlowLayoutPanel

I have a C# 4.0 Winform app, the main form of which is visually divided in half: a TreeView on the left (for navigation of data) and a FlowLayoutPanel on the right. The contents of the FlowLayoutPanel changes based on user interaction (mainly with the TreeView).
The content to be shown in the FlowLayoutPanel is comparmentalized into a number of "blocks" - some are UserControls whilst others (I'm embarrassed to say) are Panels containing various Controls.
My issue is that the number of "blocks" is now too many to see in the Visual Studio form designer, and I can't make the form large enough to see them all; this makes it hard to verify how the UI will look without running it.
How can I manage the contents of the FlowLayoutPanel so that I can see all of the controls, or am I going about it wrong?
While in the designer, make sure you have AutoScroll property set to true, which will enable you to scroll the FlowLayoutPanel child controls while in the designer view.

Some controls on a page are not visible for MS UI Automation

We have an application with StartPage.xaml, where control template for TabControl defines some grids and stack panels. There is an itemPresenter in that template in the middle of the xaml, and a stack panel below it. While it works fine for a user, MS UI automation can see only tab items inside the item presenter, and nothing else that is defined on the same level in the template.
I tried to add standard button inside a stack panel which can not be seen by MS UIA to check if that is a problem related to custom user controls we have, but that standard button is also not visible for MS UIA.
If I use Snoop, I can see all the elements from the template in a snoop's tree on the corresponding levels of template hierarchy. But MS UIA still can't find them.
What can go wrong here with controls that will prevent MS UIA from finding them on a page?
Finally I was able to detect the problem. TabControl was templated with a bunch of different controls, while AutomationPeer stayed the same which is only aware of TabItems as TabControl children.
I subclassed TabControl and overrode OnCreateAutomation to create and return my GenericAutomationPeer, which can enumerate all child UIElements of this control and voila - UIA Verify can now see that additional controls from TabControl template.
GenericAutomationPeer implementation was found here: http://www.colinsalmcorner.com/2011/11/genericautomationpeer-helping-coded-ui.html
Great thanks to the author of that article!

Creating a "mergeable" toolbar with Prism regions?

I'm developing a WPF application where I would like a common toolbar along the top of the screen (when I say "toolbar" it won't be a WPF ToolBar control, more likely just a series of image buttons resembling a Windows 8 app bar). I'm using Prism navigation.
What I had in mind was that this toolbar would live in the main window, and always be visible throughout the application. The toolbar would include a couple of standard buttons such as "Exit" and "Help".
Below the toolbar, the main window essentially just contains a large Prism region. When I navigate this region to a view (call it "view1") I want view1 to add additional buttons into the toolbar.
Now, "view1" may have Prism regions of its own, and when one of these is navigated to a view (call it "view2"), view2 should be able to add buttons of its own, alongside the "standard" main window buttons and the buttons added by view1.
It goes without saying that the relevant buttons should be removed when navigating away from a view.
I'm sure I could roll my own solution, but wondered if I could simplify things with Prism? I thought about putting a Prism region in the toolbar alongside the "standard" buttons. "view1" would then navigate this region to a view that basically just contains view1's buttons. This "view1 button view" could itself contain a region, that view2 could navigate to its own "button view". Is this viable, or is it going to get too complicated?
It sounds like you might be complicating it a bit, or at least you lost me at the end...but that doesn't take much today!
A suggestion: Your "toolbar" could be, for example, some ItemsControl where your ItemsSource is a collection of some class ToolBarOperation. This class could contain a description to display to the user and an ICommand to perform when clicked. Style your ItemsControl's items to be buttons and bind each button's command to your class's ICommand. This collection would be populated by the currently visible view's viewmodel (i.e. View1's viewmodel would already know what commands it would be responsible to perform. When View1 is loaded, fill the collection with ViewModel1's list of ToolBarOperation.)
So, to answer your question, I don't think you need anything Prism specific (except maybe their implementation of DelegateCommand)...the "Controller pattern" discussed in the documentation might be helpful. But it shouldn't be hard to accomplish what you want with Prism alongside.

Re-using Buttons in WPF

I have a bunch of different objects that are commonly edited in the same TabControl using different DataTemplates, but I want each DataTemplate to have a common look and feel with Ok and Cancel buttons at the bottom right of each tab that will close the tab or save the content and then close the currently selected tab. What's the best way to place buttons on each tab ? Is there a way to do it without copying and pasting the buttons and stack panel across all of my data templates ?
Sure, you can create your own OkCancelSaveControl. In WPF, creating a "user control" is much easier than it sounds. Here is a tutorial. In a nutshell, you
create a new user control,
create properties in the user control that give the your control the information it needs to perform its duties (e.g. the tab that it's supposed to close or the data object that it's supposed to save),
if necessary, create events that the user control raises (OkClick), in case some tab requires special treatment.
I would make a custom control, lets call it MyCoolTabItem, that inherits from the TabItem class, and just throw your buttons into the control. Then just add a MyCoolTabItem instead of a TabItem to all of your TabControls and it will have all of your buttons on it.
You could make a base view class that held those buttons. Views that needed the buttons would inherit them and common functionality.

how can i change controls when a button is pressed in xaml

i am trying to create a wpf app and have different parts in user controls.
in the navigation i have some buttons (now using the ribbon ctp). is it possible to change the main user control when different buttons are pressed in xaml. or is this just a bad way to do things?
sorry, really new to xaml and im trying to get my head arround it.
Further to what Carlo has said,
The way we do it is to have a blank grid in the place you want your controls to all appear and then use BlankGrid.Children.Clear() and BlankGrid.Children.Add() to set up which control is visible in this position.
We found that was the nicest programatically as we have a large number of custom controls, but Carlo's method would work nicely if you wanted to use the designer.
I think this is a pretty regular procedure in WPF. In my experience, me and other programmers put the controls where we want to show them and make their visibility hidden, collapsed or visible depending on what we want to show the user.

Resources