Implement x:Bind for WPF
Please implement the x:Bind feature from Universal Windows Apps in WPF.
See http://channel9.msdn.com/events/Build/2015/3-635 for a presentation on x:Bind.
Roland Harrison commented
Any comment from Microsoft?
Lutz Fritsche commented
We develop a large ERP software with a metadata based generated WPF client.
x:Bind would be very important for us.
(by the way, decoupling View from ViewModel may sometimes be necessary, but it is not a MVVM pattern, see https://msdn.microsoft.com/en-us/library/hh848246.aspx)
Dont like UWP, WPF is much better way i like the file system and local resurce small country and small bussines and family and privacy is imperative to protect.
Big corporative intrest of few mega rich people who leading big countrys around world and want to control the all world destroy world we know.Only for this people all must be on his cloud regardless of the cost and only he be the one to make money.Microsoft please correct this unjustice.
It's a shame that we don't even have a comment from MS on this highly voted feature. They seem to be fed up with WPF much earlier than WinForms.
Agree with Raffaele Rialdi (below).
Stefan Koell commented
Please don't stop innovation on WPF. UWP is not there yet and still has many limitations (interop, elevation, etc). Also Win10 as a min. requirement is still a showstopper. Innovations like this are badly needed!
Kelly Elias commented
WPF needs the x:bind and x:phase enhancements badly. Implementing those would solve so many problems I'm currently dealing with. All these look solid and really should be part of WPF.
Joe Bussell commented
This remains a critical need for WPF. Anything that can be done in a UWP program should be available an a WPF program. WPF > UWP for our needs, but we are feeling a bit neglected seeing all the shiny new toys going exclusively out to UWP devs.
Why not compile normal WPF bindings where x:DataType is set?
Raffaele Rialdi commented
Good idea, but please not x:Bind as it is not MVVM friendly.
Since WPF allows markup extensions and the use of code generation (Linq Expressions), I would opt for something *better* than x:Bind.
I mean something that is MVVM-friendly (x:Bind is not) allowing decoupling View from ViewModel (x:Bind requires the binding is done on the code-behind)
We need it!
Yes this is needed.
My existing customers are not ready to move from Windows7 any time soon and have no interest in developing apps for the store. They want line of business applications developed in WPF and for these to be fast, memory efficient and stable.
Add it please
Jeff Arnett commented
Either re-invest into WPF or make UWP app model be able to escape out to service/system level access (file system, drivers, registry, etc.).
With the WinIoT flavor of Windows 10 having an "embedded" flag to allow this will the desktop flavors of Windows 10 follow suit? If so maybe adding the system access and powerful WPF features to UWP is the way to go?
...when I say "backport" below, they don't need to be compiled at WPF/Silverlight in my opinion, just allow the new syntax and fallback to implementing it internally using the old latebound way for starters, then later consider if will fully implement at compile time
all such additions to XAML (and especially the "using" at the namespaces that breaks older XAML) should be backported to both WPF and Silverlight. Especially with "using" means that you can't share XAML between WPF/Silverlight and Universal apps, thus you have to maintain separate XAML with no way to implement that support as a compatibility layer yourself
John Bowen commented
@Jim Fielding - x:Defer has already been announced as a coming WPF feature. http://channel9.msdn.com/Events/Visual-Studio/Connect-Live/Visual-Studio-WPF-Team-What-we-are-up-to
Jim Fielding commented
Along with the other two XAML performance improvements for Universal Windows Apps announced at build2015, x:Phase & x:DeferLoadStrategy.