I'm working on a binding prototype for a new project and ran into a snag with Blend and binding. We're trying to us a BindableEntity class with the ICustomTypeDescriptor interface implemented. The reason for this is to allow a separation between Entity Framework and binding on the UI.
The problem we've run into is Blend using reflection instead of the ICustomTypeDescriptor implementation for our property descriptors. For example, when I click on the binding for one of the text blocks in the Main Window I need the FirstName and LastName properties to show up so the designer can select them. I don't want them to use a custom binding. Ironically, Visual Studio demonstrates the desired behavior.
Here is a link to the
Source Code
Does anyone have any ideas on how to accomplish this?
Related
I have a whole bunch of RoutedUICommand commands which I fire from different places, using the Command attribute in XAML.
They all are bound right now in my MainWindow.xaml and in my MainWindow.xaml.cs I have a handler for each of them. I have set it up this way, mostly because I resolve the MainWindow class with Unity and it receives all necessary dependencies (i.e. domain services and etc). If I bind the command to a UserControl, I wouldn't have those services available there and also it seems wrong that a UserControl which is given a DataContext, but would be allowed to manipulate its or another context.
My question: does this seem right? To me, something seems off about handling all of the commands in a single central place, especially the main window code behind.
I am new to WPF and can't tell if this is right or wrong. Any advice is appreciated.
You should handle them in your ViewModel. The common pattern in WPF applications is MVVM.
M - model (i.e. DB)
V - view (.xaml files)
VM - a class that is set to be the DataContext for you view. You should do all the logic, binding here.
I suggest having a look at some MVVM frameworks that can simplify the development.
Some of the popular ones are:
Caliburn.Micro
MVVM Light
WPF provides two implementations of the ICommand interface; the System.Windows.Input.RoutedCommand and System.Windows.Input.RoutedUICommand where the latter is a subclass of the former that simply adds a Text property that describes the command.
However, neither of these implementations are especially suited to be used in a view model as they search the visual tree from the focused element and up for an element that has a matching System.Windows.Input.CommandBinding object in its CommandBindings collection and then executes the Execute delegate for this particular CommandBinding.
Since the command logic should reside in the view model, you don’t want to setup a CommandBinding in the view in order to connect the command to a visual element. Instead you should create your own command by creating a class that implements the ICommand. All MVVM libraries out there such as Prism, MvvmLight and Caliburn Micro already have such an implementation. They are usually called DelegateCommand or RelayCommand. Please refer to the following links for more information about commands and how to use them in an MVVM WPF application.
MVVM - Commands, RelayCommands and EventToCommand: https://msdn.microsoft.com/en-us/magazine/dn237302.aspx
Handling events in an MVVM WPF application: https://blog.magnusmontin.net/2013/06/30/handling-events-in-an-mvvm-wpf-application/
I just started looking into WPF and MVVM-Light a couple of days ago. At first I created a single windows desktop app and now I want to create a desktop app with several pages.
I read this tutorial and I think I understand the concept.
But I have one question. MVVM-Light uses the ViewModelLocator to avoid having a strong link between the view and the viewmodel. But does using a DataTemplate in the MainWindow.xaml (to associate view and viewModel) not go against this principle? Is this the right way to do it?
Lots of people use the DataTemplate method,that's fine. The other widely used method, setting DataContext to your ViewModel in code-behind, also creates a "link" between them. If there is no link, nothing would ever work at all.
I think I have a pretty good understanding of the MVVM design model, however I have a quarm with it in regards to WPF, Command bindings and how we are meant to use them.
To bind commands to the XAML directly we are meant to implement the ICommand interface within the ViewModel. Now, the ICommand interface is part of the PresentationCore.DLL, which, correct me if im wrong is part of WPF not the base .NET framework.
Isnt the whole point of the ViewModel and Model that it should be totally UI independant? For example, if I implement ICommand in my ViewModel and use it as a data context in order to bind commands from the XAML, isnt my ViewModel then dependant on the WPF frame work (in particular the PresentationCore.Dll).
What I mean is, if I was to go and try to use my Models and ViewModels in lets say a Windows Forms environment, I would have to reference the PresentationCore.DLL even though I shouldnt need it because im using Windows Forms not the WPF framework.
This seems a bit odd to me, am I missing something here? Is there another way I should be doing it to keep my Model and ViewModel totally UI and UI Framework independant, but still be able to utilise the Command binding in XAML?
Thanks in advance!
I also had this kind of problem but not in wpf but in POCO classes. What i did was I created two partial classes in two different assemblies. Like you create one partial class which is not presentationcore.dll dependent in your VM project and create its partial class in another assembly(say WPFVM) which implements ICommand stuff. Now for Winforms stuff add only VM project reference to View project and for WPF stuff add references of both VM and WPFVM to the View project. I hope this will help.
The point of MVVM is to have the view just be a view, and nothing more. Putting ICommands into the view model helps this as it pulls the code away from the view. Where you will run into problems is if you have to access something on the view that is not a dependency property, which means you can not bind to it.
In my opinion MVVM is very popular with the WPF, Silverlight because it naturally fits into it. The data binding concept in the XAML allows the Views & ViewModels to be bridged using a single property which is the DataContext. As no longer your logic is tied to controls, you get better testability, design-code separation and maintainability. You may be able to implement the MVVM pattern in other places also, but in WPF and Silverlight, it fits so easily due to its data and command binding support. I have read somewhere that, Don't take patterns religiously. They were made to make your life simpler rather than giving you more problems while following it. For Winforms i think there are better patterns, If you are focusing in reusing the business logic, move them out of your ViewModels to seperate classes something like serviceproviders or serviceagents and share them between your Winforms and WPF apps.
This has changed in .NET 4.5 compare
.NET Framework 4.5
.NET Framework 4
At best, I am a UI novice, but I am a pretty good OO developer (if I don't say so myself). I am confused as to how to work with the designer. I am developing a Windows Forms application. I have a control (TabPage) that I derived from System.Windows.Forms.TabPage that I want to place on a System.Windows.Forms.TabControl control.
public class MyTabPage : TabPage
{ ... }
I am not sure how to get the designer to use my control.
A fellow developer looked at this for me as suggested that I add more information.
I've prototyped a WinForms application. The application has a TabControl, with three tab pages on it. Each TabPage has a SplitterControl with a DataGridView control in each half of the splitter. The two DataGridView controls form a master-detail view of some data we need to edit. I've added a bunch of event handlers to each DataGridView control and each time the handler code is placed in the form. The form is getting pretty crowded and would like to use OO techniques to clean things up.
I would like to redo the prototype now and because each TabPage is behaviorally identical, I would like to use OO to abstract away some of the complexity. This is where my lack of experience with the designer comes in. There must be a way to use the designer for something more complex than my origonal prototype.
You aren't really changing the behavior of the TabPage, it's just a container after all :). The TabPage and TabControl are rather tightly coupled, and they probably should be. Your "control" is what should be placed on the TabPage. So define your user control as a panel with a splitter and two datagridviews and then just drop your user control on each TabPage in your app. The Tab Control/Page tandem will still work automatically and your custom code will be in the appropriate control.
Unfortunately, there's no real practical solution to your problem. You'd have to create a custom TabControl as well and give it its own designer so that it will create instances of your derived class instead of the default TabPage class.
Sadly, the TabControlDesigner class in System.Design.dll is internal and can't be derived from. You'd have to write a complete replacement for it. That's difficult, it is a pretty advanced designer. You could have a look-see with Reflector to find out what it takes.
UserControl
Simply create a user control that contains your control. Then it will be available in the ToolBox window of Visual Studio.
For more details, Understanding the User Control Designer...
A User Control is similar to any other
class, but with the added ability to
be placed in the Toolbox and displayed
on a form.
The tutorial differs a bit from Visual Studio 2010 but I'm sure you will get through it.
TabPage Control
As for the TabPage control, you can't use it stand-alone in the designer. It must be part of a TabControl.
The TabControl is built to contain TabPage controls. If you use the designer to add/remove any TabPage, in the back-end it does "new TabPage", it can't determine that it needs to create a new instance of your derived class of TabPage.
Other Suggestion
A TabPage is just a container, I can't figure out why you need to override the TabPage control. I know you have added some information to your question but you may have to revisit it again so we can better understand.
Since the TabPage is a container, you should create a UserControl which contains your SplitContainer and DataGridViews. Therefore you would be able to reuse that UserControl on each TabPage.
The designer is just a complement to UI programming, it is not mandatory. You can add a UserControl to a TabPage without using the designer.
I may be off the track here, if so please provide more details. A visual prototype of what you need may help.
It's been a while, but I thought I would answer this question.
I was able to get the OO implementation I wanted by splitting the control up. The control is implemented pretty much the same as the prototype. I then created a control binder class hirearchy with derived classes to contain the specific behavior(s) I needed. The control has a reference to the binder base class and calls binder functionality as needed. The derived binders override properties and methods as necessary. Pretty much a textbook OO solution.
Where I was stumbling was in thinking that I needed to have a control hirearchy.
Thanks everyone for your help. I was under some pressure when I asked this question. It's amazing how much I've learned in the months since.
I'm currently working on a brownfield application, it's written with winforms,
as a preparation to use WPF in a later version, out team plans to at least use the
MVVM/Presentation model, and bind it against winforms...
I've explored the subject, including the posts in this site (which i love very much),
when boiled down, the main advantage of wpf are :
binding controls to properties in xaml.
binding commands to command objects in the viewmodel.
the first feature is easy to implement (in code), or with a generic control binder, which binds all the controls in the form.
the second feature is a little harder to implement, but if you inherit from all your controls and add a command property (which is triggered by an internal event such as click), which is binded to a command instance in the ViewModel.
The challenges I'm currently aware of are :
implementing a commandmanager, (which will trigger the CanInvoke method of the commands as necessery.
winforms only supports one level of databinding : datasource, datamember, wpf is much more flexible.
am i missing any other major features that winforms lacks in comparison with wpf, when attempting to implement this design pattern?
i sure many of you will recommend some sort of MVP pattern, but MVVM/Presentation model is the way to go for me, because I'll want future WPF support.
Thanks in advance,
Erik.
Please take a look at Update Controls .NET. It is an open-source library for Winforms, WPF, and Silverlight that keeps controls up to date as data changes. You can start using it now for Winforms, and then transition over to WPF without changing your Data Model or View Model code.
Unfortunately, it does not solve the Winforms command binding problem. Your button click events will not port from Winforms to WPF. But it does take care of the data binding problem.
You might find the WAF Windows Forms Adapter interesting. It shows how to apply the Model-View-ViewModel (MVVM) Pattern in a Windows Forms application. The Adapter implementation provides a solution for the missing Command support in Windows Forms.