Partilhar via

Request for Feedback (WPF VNext)

  • Artigo

So have you tried out .NET 4. If not, do give it a try. We have a bunch of new WPF features in .NET 4 and it was covered as part of the WPF features series. Now that we are close to release, whats next. This is where your feedback is invaluable. We listened to your feedback from 3.5 and incorporated several suggestions into .NET 4. Now its again time to ask for feedback to drive the direction for the next release. We would love to hear your comments\opinions on the following areas

· What are the features you would like to see in vnext of WPF? You can also vote for your features here.

· How can we improve the curve in learning WPF? Are there things we can simplify?

· Feedback on tooling support (IDE, Loc, Designers, perf tools,..)

· What do you think of the community support for WPF developers? Can we do better?

· I have seen some posts expressing reservations adopting WPF (e.g. especially when coming from a Winforms background). In general, what hiccups\reservations (if any) do you (your team) have adopting WPF?

· Any learnings\experiences adopting\using WPF

· Any random feedback not covered by the above J

Send in your feedback. We are all ears J

 

Share this post

Comments

  • Anonymous
    March 05, 2010
    I believe the biggest request is controls.  I would like to see the same controls ported and released that are included in the Silverlight Toolkit.  Also, get the controls added to WPF that are in WinForms (e.g. DataGridView ).  Love to see a Dock Manager included like the one in VS2010.  Thanks a bunch:)

  • Anonymous
    March 05, 2010
    Somewhat prioritized: Further improve cold startup. This is a major pain point. Reduce the need to write an insane amount of converters (expressions in binding, maybe?) Stop treating binding errors as warnings and throw an exception (major breaking change) Make it easier to bind to a property in the codebehind, maybe some syntactic sugar for 'this' Intellisense for xaml bindings where applicable (Resources) Stop using App.xaml/StartupUri in the WPF project template, use a proper program.cs instead. Any non-trivial program will want to do stuff before launching the main window. Encourages bad code. Fix design-time merging of ResourceDictionaries in Cider so we don't have to repeat the same Dictionary everywhere just to have something show up in the designer. A usable designer (one of the motivations for xaml in the first place, right?). Sorry about the long list, I couldn't help myself. I've been working with WPF a lot lately.

  • Anonymous
    March 05, 2010
    Improve localization. the locabaml tool doesnt work and this should  be supported in VS. Also XAML 2009 features should be supported in compilers Better performance

  • Anonymous
    March 05, 2010
    WPF 4.0 is pretty good, the new controls come in handy, and I especially love the fact that InputBinding.Command is now a dependency property, which makes things much easier when using the MVVM pattern. A few things I'd like to see in the next WPF release :

  • better support for MVVM. For instance, a built-in way to bind events to ViewModel commands
  • better designer in VS ; it almost never does what I actually want it to do, so I almost always resort to writing XAML manually. For instance, the design-time docking behavior should depend on the container : when I drag a control to a Grid, I expect it to "dock" in one of the grid cells, not to place itself in some arbitrary absolute position. In a DockingPanel, it should dock to the nearest border or fill the whole area (like document windows in VS)
  • Fix that annoying bug : when you use a custom markup extension, it breaks the designer if the ME is defined in the same assembly
  • Improve localization ! LocBaml is the worst localization tool ever : very tedious to use, lots of manual steps, you have to modify the XAML to add x:Uid tags, and so on... Why can't it be as easy as it was in Windows Forms ? I ended up coding my own localization lib, using .resx files (which should definitely be the "official" localization technique, as it was in Windows Forms and ASP.NET). The following article contains some interesting ideas about localization using various techniques (markup extensions, attached properties...) http://wpflocalization.codeplex.com/
  • Make it easier to navigate the visual/logical trees : perhaps some extension methods on DependencyObject to find an ancestor of a given type, or enumerate all children (can be done by anyone, but it would be nice to have it built-in)
  • I second Robert's ideas about expressions in bindings, and a "real" program entry point (Main method) WPF is a really cool product, but it still needs improvements to reach the same productivity level as Windows Forms

  • Anonymous
    March 05, 2010
    The comment has been removed

  • Anonymous
    March 07, 2010
    Provide better perf tools. Have a simple notation than XAML. Agree with THomas  -loc is a mess

  • Anonymous
    March 09, 2010
    The comment has been removed

  • Anonymous
    March 09, 2010
    The comment has been removed

  • Anonymous
    March 09, 2010
    My request involved the CLR and WPF/SL. I would like to be able to  make "Binding" on Interface property. Example : I Have a list of IPerson. I want to be able to bind a TextBox.Text property on IPerson.FirstName. Regards

  • Anonymous
    March 09, 2010
    It seems that there are no good solution in WPF to migrate projects using virtalized listviews in thumbail mode. We just have a Virtalized StackPanel, that's good, but we need a Virtalized Wrap panel for a lot of projects !   So please, please... make a good one (with good keyboard navigation)

  • Anonymous
    March 10, 2010
    don't redo the terrible mistake you did with ASP.NET: document the background of WPF technology and publish some true good practiced sample. Not the one we have in the today's documentation.

  • Anonymous
    March 13, 2010
    WPF is great but: *Extremely non user friendly to install *Slow to start *Can be improved on perf But the 2 first one are killing it

  • Anonymous
    March 15, 2010
    The comment has been removed

  • Anonymous
    March 24, 2010
    Please make sure that you keep WPF in sync with new features of Silverlight.  We all know that they are trending towards a unified platform in the future.  However in the meantime, control vendors like us have to develop separate codebases, each of which are sometimes forced to have different features.   For instance, Silverlight has the neat plane projection feature but that's nowhere to be found in WPF so there's no way we can write code for a 3-D UI control that can be used on both platforms.  I know we could do a full-blown 3D environment in WPF but a lot of times we want to keep things simple and just plane project a visual. There is a lot of momentum and innovation going on in Silverlight.  We really need the WPF platform to keep up.  Keep up the great work, we love where the platforms are going!

  • Anonymous
    March 26, 2010
    The comment has been removed

  • Anonymous
    April 17, 2010
    We are using WPF for digital signage. The usage of one gui-thread block us in showing properly scrolling marquee text together with alternating videos and pictures. Loading a picture e.g. will block the effect of the scrolling text. We want to be able to run a control in its own thread independent of the gui-thread. Another annoying issue is the so-called "Airspace" problem. We cannot properly integrate eg the webbrowser into our pages. Make a better business case for WPF and put WPF at least at par with Silverlight. Maybe swap the product managers.

  • Anonymous
    April 23, 2010
    Please give us the ability to disable the pre-multiplication by alpha of colour data in bitmaps with alpha data in them. I can understand the general need to follow a consistent method throughout the UI with alpha, but e.g. when the user knows that a specific bitmap is only ever going to be processed by their own custom pixel shader, the data should be able to be passed into the shader without any pre-processing if required. The user can easily handle the alpha calculations in the shader if they need to. This is the whole point of using pixel shaders.