I am basically new to WPF.I have 2 Xaml files.
WpfCurrentSessionViewer.xaml and MainWindow.xaml.
Say WpfCurrentSessionViewer acts as a control which has labels in it.
MainWindow is the xaml where we need to inscribe the control.
Say in Asp.Net applications , we have an aspx page and a master page.
In similar way I need to do that as WpfCurrentSessionViewer.xaml acts as a master page
and MainWindow.xaml acts as an aspx page .
Regards,
Sachin K
I think your question contradicts itself in terms of which way around the two controls are:
Say WpfCurrentSessionViewer acts as a control which has labels in it. MainWindow is the xaml where we need to inscribe the control.
WpfCurrentSessionViewer.xaml acts as a master page and MainWindow.xaml acts as an aspx page.
Either way, it sounds like you need to have one Window and one UserControl (or CustomControl, but if you're new to WPF you'll find a UserControl easier).
What you are talking about is UI composition, or view composition. This is usually achieved in WPF with a ContentControl which has a Content property which you can set to any type, in your case, an instance of your MainWindow type.
I would consider adopting the MVVM design pattern when building WPF applications, and using an MVVM framework such as Caliburn.Micro, which makes view composition very straightforward.
Are you talking about frames ? There's a very good article about using frames here :
http://www.paulstovell.com/wpf-navigation
Related
I'm on writing a simple application, it has a menu and when user choices each MenuItem, i want to change my window's content to display the selected content.
i have two option to that.
i can add a <Frame></Frame> to my window and write some pages.
i can write some UserControls and put them in a ContentControl
as user fires MenuItem click event.
so I'm confused to select the right choice for this purpose.
Navigation can be succefully implemented by using Frame/Pages or ContentControl/Views. It is a matter of choice.
However, Frame/Page have some gotchas, e.g. page.DataContext not inherited from parent Frame?
If you don't need isolation specifically, then stick to ContentControl. Navigation in prism framework is built with regions which are located in different type of controls (e.g. ContentControl, TabControl), not Frame (see docs)
one more approach for simple navigation is ViewModel based.
Examples:
WPF MVVM navigate views
Navigation with MVVM by Rachel Lim (external)
Folks
I am working in UI design in a project where our team chose to decouple C# and XAML as much as possible.
I've been having trouble to create Styles for many common widgets (buttons, etc.) and some UserControls, specially because I don't-want/don't-know-how/am-not-supposed to use code-behind.
What I want to do is to be able to change properties of elements that are "deep within" the layout tree of my UserControls.
For example, suppose I have an UserControl that is a Border, which contains a StackPanel, which contains a colorful Ellipse and other things.
I want to be able to instantiate this user control and change only the color of the ellipse, like this:
<MyUserControl Background="Gray" EllipseColor="LightGreen" />
where "EllipseColor" would be some "custom" property defined in the UserControl.
I tried DependencyProperty within styles, but got no success, although I "feel" there must be a simple way to do this.
Any help (links, code snippets) would be much welcome.
Thanks for reading.
The "No Code Behind" rule in MVVM is for keeping the View and the ViewModel completely separate, and should not be used for view-specific code such as DependencyProperties. Its like saying "Build a house out of these square blocks, but I want a rounded roof and you can't create your own building blocks". The whole point of DependencyProperties is to create additional Properties for your Views that don't already exist.
The important bit is that the View doesn't directly reference the ViewModel, and vise versa.
In your case, I would either create a DependencyProperty in the Code Behind for your UserControl for EllipseColor, or use something like the Background property of the UserControl and bind my Ellipse fill color to that.
I have a question about doing the custom painting operations in WPF MVVM View. My case is:
External manipulation of model data happens, and the observable collection of data to be shown is modified (storing some data to be shown in a diagram). I have to react to that change in my view, and custom layout the diagram elements (remove the ones not used, place new ones, calculate positions on diagram canvas). How can I do that, and what would be the best way to do it conform to MVVM pattern? I cant subclass the diagram class, as it is sealed. The diagraming framework used is MindFusion.
Edit: A solution was proposed on MindFusion Support forum, and it works.
http://mindfusion.eu/Forum/YaBB.pl?board=wpfdg_disc;action=display;num=1306412889;start=0
Last I checked MindFusion diagraming component for WPF, it supported MVVM through data binding. If you bind the diagram to a ObservableCollection you can then write custom Node Templates which are basically DataTemplate that will render YourDiagramModel items on the diagram panel.
Unlike WinForms you usually don't need to manually refresh or paint control surface in WPF custom controls.
I have an app with MVVM which works fine. Now I want to replace one of my controls with a dynamic control. By dynamic I mean that I have no idea what control this is, only that it is a GUI control. It could be something as simple as a image, or a custom third party user control that will be created by someone else after this app is done.
Can someone shed some light on how this can be achieved in MVVM? I've done it before a long time ago using ListBox or similar (iirc) to generate GUI elements (don't remember details). But I'd like to learn the theory behind it this time.
Edit:
Lets say the View contains a list of instances of for example System.Windows.UIElement. I want to display all of these UI controls on a surface (for instance in a stacked control).
You could create a View that exposes a Content property as a placeholder (so a ContentControl might be all that is needed) The content property could then be set to the dynamic control.
You would have to add a little reflection to dynamically load the assembly and instantiate the required control.
The dynamically loaded control would have to access the data by using the DataContext property. If the dynamic control is MVVM too it might have its own ViewModel so you would have to find a way to load that too (reflexction again?) and point the DataContext of the control to the loaded ViewModel.
Does this make sense, is this what you are looking for?
I've been doing a prototype in WPF without using MVVM. It's got to such a size now that I'm refactoring it to use MVVM.
When I started the project, I jumped straight in and created UserControls for lots of things.
I'm now breaking things in Views and ViewModels. But, I'm ending up with Views that contain UserControls; the UserControls have bindings to what are now objects in the Model.
So, is the notion of UserControls now dead in MVVM? What I mean is, in the past (WinForms, ASP.NET etc.) you'd have a project called 'Controls' and reuse these. Is the 'View' in MVVM a direct replacement of the typical UserControl?
A UserControl in WPF is little more than a ContentControl with a few tweaked default property values. A ContentControl is little more than a piece of content that can have a template applied to define its look.
The way I do MVVM skips the middleman and defines views as DataTemplates. Then you need only stick your VM into WPF's visual tree somewhere, and WPF will render it with your DataTemplate. For example:
<ContentControl Content="{Binding SomeViewModel}"/>
<ItemsControl ItemsSource="{Binding SomeViewModels}"/>
The way I see UserControls in the MVVM world is as a View. Rather than thinking of your WPF form as a single view, you can think of it as a composite of one or more views. So a UserControl can encapsulate a standard re-usable view that can be incorporated into multiple composite views. Great for re-usability and still they're still testable.
Mmmm... when I had user controls I just passed the DataContext from the View to the user control (the subinfo needed by that user control). But is true, that sometimes is hard to fit ViewModel with Views, UserControls, ...