Any news on WPF 5?

Question

Can you share some information on WPF 5? When we should expect a new CTP?

Dany

Answer 1

Hi Dany,

Not sure when a new CTP for v.next will be available. But I think it's a good time to write down a wish list here so the WPF team can hear from you.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [e-mail]

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The All-In-One Code Framework Project
My Blog (in Simplified Chinese)

Answer 2

Here's mine (i'll keep adding here as I think of more):

 

1. MultiScaleImage

 

[EDIT: I have to second Dany's points on animation performance (big one for me) and output to video]

Answer 3

My list of things I wish. The first and the second point are really important to me.

1. Make WPF and Silverlight API equals: Same API, same controls, perspective /composite transforms, web cams.

2. Improve performance. Here are the points:
   a. Animations are not fluid when Updating the UI from a background thread for example.
   b. On scrolling, when the VirtualizingPanel needs to create items, it does not scroll smoothly.
   c. If a double thread is a good choice for Silverlight on the Windows Phone, why not use the same principle in WPF. Might be interesting in the background of the WPF platform, to allow DispatcherObject to be accessed by more than one thread.

3. Add Blending Modes.

4. Make MarkupExtension a DependencyObject and add SetResourceReference available to DependencyObject.

4. Add DynamicResource support to the Style BasedOn property so we can used it in different ResourceDictionaries.

5. Nice to have : Implement "Smooth Scrolling" with deceleration on the ScrollViewer. Either use a Behavior or directly on the ScrollViewer.

6. Make the WPF toolkit compatible with WPF 4! I need the AutoCompleteBox.

7. Complete the new System.Xaml API. We need support for Attached Properties (those in WPF).

8. Nice to have : Add support for rendering WPF content as a Video.

9. Fix the Maximize window when using having no WindowState. The Window should behave like all other window and not overlapping the TaskBar.

10. Integrate Xna and Wpf. Xna is faster than Wpf in some scenarios like games, particle effects. We can also achieve blending mode in Xna.

Dany

Answer 4

1. Add .Sort() on ObservableCollection.

2. Add .AddRange() on ObservableCollection.

3. Add a TimePicker so the Calendar control can be really usefull :-)

Answer 5

It would be nice if triggers could have an option for being value exclusive...in other words right now they can only check for a value, it would be nice if they do just the opposite and see if it's anything other than a specified value.  I know it can be done with a converter, but it's a pretty simple task that I've done frequently that would be easier if there was a property of a trigger exposed for this purpose.

 

Thanks!

Aj

---

If at first you don't succeed, skydiving is definitely not for you!

Answer 6

Wishlist:

1. Go through every single WinForms control and ensure that it has a WPF equivalent.  Then go through each WPF control and ensure all of its WinForms counterpart's capabilities are duplicated and easily available.  Having to jump through ridiculous hoops with custom attached properties and markup extensions to implement something that was a simple property on WinForms is not only a pain, it's damaging to the credibility of the platform itself.  If WPF wants to be taken seriously it has to be suitable for LOB.  It's understandable that we might take a few steps backwards for the release of .NET 3.0 but we're a few years down the road now.

Example: AutoComplete on text box, various useful properties that could lock down the browser control, to name but a few.


2.  Integrate the behaviours model directly into the framework.  It's embarrassing to have to ship a DLL from Expression along with a small EXE just because you wanted some animated layout in your listbox.  This model could be more easily accessible also - I'd go so far as to suggest built in animations for controls that can be enabled, overridden, or completely customized.  Smooth scrolling, animated layout etc are common desires and once enabled I suspect it would be rare that a developer would want to change/customize them anyway - why not just have a simple on/off property for them?  Developers would use them far more, they're actually useful for users (and not just some silly visual glitz), and if lots of developers were using this it would give WPF an immediate obvious edge over old school technology, pushing its implementation out.

3.  Merge the Silverlight and WPF teams.  Right now.  Microsoft recently, finally, announced that they were merging the C# and VB.NET teams so as to create one language (.NET) with two different dialects (C, BASIC).  This is smart and keeping the languages parallel is good for everyone.  Except now we're going down the same old route with WPF and Silverlight, where some simple XAML features were available to WPF and not Silverlight, and vice versa with other features.  I haven't really played with Silverlight 4 and I understand that a lot of this may have been addressed by now, but bringing them into parity with one another would be a big boon for developers.  Imagine being able to switch your build target from .NET Framework 4.0 Client Profile to Silverlight OOB and just have it recompile?  It's completely understandable that certain features would be unavailable in SL for cross platform reasons, but for the most part they should be identical.

4.  XAML enhancements.  Microsoft likely never thought we'd be writing UI in XAML (who woulda thunk it, right?) but even in VS2010 the designer is not up to spec for my liking.  However, I've become very accustomed to writing the XAML and watching the changes dynamically on screen.  The latest Intellisense features are nice, but they could be a lot better (how about some Intellisense on markup extensions to make data-binding a bit easier?).  Cider still seems a bit fragile also (I've crashed VS2010 once or twice lately) and on occasion XAML is unnecessarily wordy.  Why do I need to create various nested nodes to create a 3-column Grid when something like <Grid Columns="3" ColumnWidths="*, 0.5*, 0.5*"> would be so much easier?  The extended syntax could still be supported for more complex layout scenarios.

5.  Accelerator keys should cause LostFocus on previous control.  This is a pet peeve but a serious one.  Let's say I have 3 textboxes bound to an underlying data-context (my ViewModel).  I also have a Button with a Content property of "_Save".  When the user clicks or tabs to the button, the LostFocus event is fired on the textbox that currently has focus and its text content is posted into its bound property.  However if I hit Alt+S, the textbox does not get the LostFocus event.  Changing the BindingMode so that it updates the property on every key-press is a nasty hack which does not always work, and this is not the way it should work anyway.  This is another serious bump in the LOB road, partly because it's something so fundemental for data entry.

6.  Pre-built pretties.  This goes back to point 2.  A library of pre-built animations to do specific things would be awesome; especially if they could be accessible from a class factory and then modified in code.  Imagine having an Animation class factory that creates an animation/storyboard which fades a control to black and white before disabling it, and you can then either immediately apply it to a control or you can modify a few properties first (the duration, easing, hue of the resulting monochrome etc) before applying it.  Some way to access it via styles/XAML would be pretty sweet too.  Same thing goes for 3D, and that's a biggie.  At present, 3D is a tremendous boon for developers who were scared off by the complexities of DirectX but might want to incorporate some genuinely useful 3D visuals/animations in their applications (yes, even LOB, and not just 3D bar charts!).  Give us a simple factory class that can quickly and effectively add create cuboids, cones, spheres, cylinders etc, add them to an existing viewport and set some automatic lighting/material properties.  Again, the developer could generate and then tweak the resulting object before adding it.  Put it this way - I want to create a basic model of the Starship Enterprise in a dozen lines of code or less; not fork out for Zam3D, export giant resource files filled with complex XAML paths, and then spend an hour trying to figure out why I can't see it only to realise that I'd got the viewport camera perspective zoomed in so far that the only thing I should be able to see is a mole on the tip of Spock's ear.


That's my rant over, anyone else? 

Answer 7

WPF 5:

- Better XNA and WPF integration

- Faster startup screen (I don't want to wait for 4-5 seconds when I do a cold start. Not everyone wants a splash screen)

- Use more bits in the RenderCapability.Tier property to store more information about the capabilities of the client graphics card

- The ability to group multiple effects and apply them to a single element (Adding an effect to an element, putting the element in a container, and adding an effect to the container cause more memory footprint)

In general, I also want:

- An active WPF Development team (seriously, SL seems to be getting the front page these days.)

- Marketing for WPF

- More .NET classes and less need to use P/Invoke

Answer 8

Hi!

Here's mine, too:

1. Keep in track and don't make WPF a Forms-clone... Finally you made a cut, and if there are people who wish the "old stuff", well, they can stay with it.
2. Improve the designer... .Net 4.0 was a good step, but still there are many issues.
3. Some more RoutedEvents would be nice :-) (espacially Preview-Events to standard RoutedEvents like SelectedItemChanged).
4. Performance-optimization...
5. Make it possible to inherit from XAML.
6. Include the new XAML-standard (espacially constructors with parameters).

I'll keep adding / removing :-)

Answer 9

I want the built-in functionality for creating a single instance application :)

Answer 10

My wishlist:

 

1. possibility to multiselect 3D objects in Viewport3D using a Geometry object (for ex. rectangle ). For now users can check HitTest using VisualTreeHelper.HitTest (Visual, HitTestFilterCallback, HitTestResultCallback, HitTestParameters ), but this method works only with 2D geometry objects in Canvas. For 3D users can select just one 3D geometry using RayHitTest.
2. Converter for .fbx file to have a possibility to convert .fbx files to XAML code (for ex. ModelVisual3D). 

Answer 11

Here's mine, too:

1. Keep in track and don't make WPF a Forms-clone... Finally you made a cut, and if there are people who wish the "old stuff", well, they can stay with it

 

Many of the people who wish the "old stuff" as you say are people who developed large, complex business applications in WinForms and are reluctant to migrate because functionality has not been duplicated in WPF.  It's easy to praise Microsoft on "making a cut" but when you have customers that will chew you out because they lost a small but important feature (file-path autocomplete on a textbox for example) you can't just turn around and tell them it's because Microsoft made a "cut" in the name of progress.

These same issues affected migration from old school technologies like VB6 to WinForms for a company I used to work for back when .NET had just reached v1.0.  The difference is that 4 years later, Microsoft had wised up and all original controls from VB6 and MFC had .NET counterparts, and they were at least as functional if not more so.

WPF was released in 2007.  Why are we still waiting?

Answer 12

I've said this in private conversations with the team and I'll say it here publicly. I'd prefer the WPF team to focus on doing those things that only the WPF team can do. Replicating controls from Winforms can be done by an enterprising 3rd party vendor. Performance improvements on animation are things that only Microsoft can do. Do you catch my drift?

I can't mention any other of my desired changes because at this point I don't remember what I've heard under NDA and what I've heard through other channels. But it's interesting looking at this list because there are some people who seem to agree with my opinion and others who feel the framework itself suffices and would prefer the attention directed at "convenience" APIs.

---

Keep your head in the Clouds as you're coding .NET http://azurecoding.net

Answer 13

I've said this in private conversations with the team and I'll say it here publicly. I'd prefer the WPF team to focus on doing those things that only the WPF team can do. Replicating controls from Winforms can be done by an enterprising 3rd party vendor. Performance improvements on animation are things that only Microsoft can do. Do you catch my drift?

Certainly, however WPF is in dire straights lately and IMO tweaking funky little things like animation aren't going to help its case.  Unless Microsoft pick a direction for it, which IMO should be LOB (as it is a natural successor to WinForms), then it will be gone within 2 years.

Saying "Just go third party!" isn't the answer for many businesses, and it puts them off migration.  A platform that's supposed to be a step forward but takes steps back reeks of being immature and simply not ready for prime-time businesses development.  But here's the thing - it's been around for 4 years now, and Microsoft are still fine tuning animation performance while neglecting core controls?  Please...

So that said, WPF is struggling as a LOB technology.  So what is it?  Is it a games development platform?  No, that would be XNA.  Is it leveraging the portability of the CLR to become a direct competitor to Flash?  No, that would be Silverlight.  So that leads us back to "what is it?" Oh that's right, it's a medium for desktop application GUI development.  Except it's still not quite ready. 

After four years.

 

Of course, in 18-24 months, assuming Silverlight continues getting all the attention, this will all be a moot point anyway.  Silverlight's OOB desktop apps are already heavily overlapping WPF's territory and I suspect it won't be long before WPF is little more than a curiosity, serving up solutions for those 1% situations that Silverlight v9 (which it will likely have hit by 2012) hasn't yet implemented on the desktop.  Pity really, as it showed a huge degree of promise.  If only they'd put the resources into making it a fully viable upgrade path from WinForms, maybe it would gain some much needed market share.

 

Answer 14

I agree with Quanta. I played with WPF and picked up a few books in 2006, but decided that the tools and technology were not there yet (understandable for a V1 release), and shelved it as a curiosity. When .NET 4 came out, armed with the news that the blurry text issue was fixed along with Visual Studio 2010 adopting it, I decided to take another look and picked up an updated book. I started porting one of my company's internal WinForms apps to WPF by porting its shell and a few screens. With RelayCommand, the MVVM architecture ported over nicely, and I can see the power of things like ItemsControl (the WinForms app would build up rich text in some cases where it was tedious to manage a bunch of dynamically-changing Labels). There have been improvements in the WPF ecosystem; we finally have a DataGrid built-in, for example, and the Intellisense support is much improved.

But, some problems immediately became apparent.

(1) There is no MDI support; fine, everyone seems to hate MDI, I'll just use a custom TabControl that gives the TabItems close buttons. (First complaint: "Now I can't have two customer accounts open side by side." Ugh, I guess I could buy an expensive docking framework, or spawn separate top-level windows where they were once children, but that feels like I'm recreating the GIMP's much-maligned interface....)

(2) It is ugly by default. Granted, WinForms wasn't super pretty, but by paying attention to alignment and spacing--something OCD developers can be good at--you could at least end up with a form that looked like 90% of other Windows applications out there. On the other hand, by default, WPF looks non-native and slightly wonky, and really re-styling controls is fantastically difficult without plopping another $400 on Expression Blend. (Why can't we buy this product separately from the rest of the Expression suite? And, no, I do not have $5k lying around to plop down for a Premium subscription.) I think it would be helpful if Microsoft ported some of the Silverlight themes (JetPack, Accent, etc.) to WPF 4 and cleaned up Aero (just look at the default styling of the DataGrid under Aero to see what I mean). For all of WPF's purported styling capabilities, the third-party theming community is essentially non-existent (a handful of themes from Reuxables, some hideous templates at XamlTemplates.net, a few wonky styles from Xceed, some broken styles in the WPF Toolkit, and a few half-hearted attempts to get the Silverlight themes working).

(3) When re-styling, I encountered a bizarre resource loading bug (http://connect.microsoft.com/VisualStudio/feedback/details/555322/global-wpf-styles-are-not-shown-when-using-2-levels-of-references). Seems basic; if this isn't working, what else isn't?

Sure, when editing the layout for a form in a LoB app, XAML wins hands down in my book as compared to tweaking with a TableLayoutPanel in the WinForms Visual Designer (going back and inserting a control later is a royal pain, and don't get me started on the hot mess that is AutoScroll). And the databinding is WPF is more forgiving than WinForms and that's a big win. But WinForms 2.0 is also decent by default. I don't *need* to buy a third-party control suite for it be functional. Why would I? That tells me that it's (1) incomplete and (2) the reason that I dropped $800 on Visual Studio Pro was to build apps using a framework that is decent by default. At the end of the day, I'm a small business developer without access to one of the 10s of designers in the world experienced with XAML styles using Expression Blend.

I just need to build an app that works and looks decent. It sounds trivial, but I think shipping a set of non-hideous set of default themes would be fairly inexpensive for Microsoft and would do wonders for the "fit & finish" of the platform.

Answer 15

I have one feature i would really like, hooks into the underlying rendering algorithm used by wpf. Being able to render WPF UI into a directX texture render target, and handle the presentation myself would make interop much easier, as well as open up WPF as a viable UI technology inside of DX fullscreen applications.

Answer 16

My Wish List:

1. Better UI virtualization support. Groups in ListBox should not disable virtualization. Also, though I know it's technically very hard, provide some form of virtualization for scrollviewers. 

2. Support multiselect in binding collections. It's such a hack to make this work, and it belongs in the data binding model.

3. Provide a standard way of inlining simple math and boolean logic into XAML. There are ways to do this, but every project ends up having a different implementation.

 

Answer 17

Add a NumericUpDown control to the list of common WPF controls ... I know its easy to implement your own but this is a really simple control which is useful in real world UIs, and should be in there by default.

Answer 18

Along with these requests we will also need CollectionView and ListCollectionView to support range changes which leads me to another request. Anywhere INotifyCollectionChanged is used it should work fully and if there is some constraint that prevents it from working fully then default behavior of doing Reset like behavior would be better than throwing an exception.

Answer 19

Single instance per user, per session on a terminal server? There is a lot of complexity to how to solve your request and implementing your desired behavior is usually pretty simple with only a few lines of code.

Answer 20

Here are a few:

• Most important #1 request for me is to create some alternative to the messy DependencyProperty declarations and INotifyPropertyChange implementations. The web is full of people pulling off numerous hacks to clean up the use of string (code smell) and other clutter introduced by these dependencies. I know Microsoft hasn't warmed up to AOP so much but I'm sure your bright developers can figure out some better solution. At least some form of Property Delegates or another way to reference properties in a way that can be checked by the compiler would get rid of the use of strings and improve the quality of a large swath of .NET code.
• Add support for visually editing Popup controls in the Visual Studio designer. This is a great control but working with it is a real bummer because in order to really see anything your designing you have to break it out into a separate user control and then reference that. Often it is nice to decide on a whim that a portion of an existing form can be hidden away (progressive-disclosure) but you don't want to move all of the events attached or work done to set up the viewmodel to another user control to achieve this.
• This one is more Visual Studio related but please consider integrating Blend or Blend like functionality into Visual Studio. The argument has been that it would be messy to integrate the design oriented tools into VS which is aimed more towards coding but the problem is that most developers are still doing the UI regardless of the fact that Blend is supposed to make it easier for non-developers to do this stuff. What we have now is a situation where we have VS but it's hard to convince management to spend the extra cash for Blend for each developer so we have a half-baked development environment for WPF. What we are looking for is at least some way to visualize templates and other resources within a resource dictionary but without having to open the whole solution in another tool (Blend).
• Missing controls from WinForms such as MDI would be great as we have to pull off quite a a lot of hacks to get this working right now by integrated in WinForms and it's still does not work 100% correctly.
• Another Visual Studio request is to support documentation for property comments in the intellisense for XAML. I don't know what this isn't supported like it is in the code editor but it's something that always bugs me.
• Better support for defining databinding within the code behind preferably with a nice fluent interface ala Fluent Silverlight.
• Develop better ways to tweak portions of an existing template instead of using the complete copy and override methods encouraged by blend. This perpetuates copy-paste type errors and makes it harder to support multiple themes.
• Either add in native support for SVG or actually start supporting XAML based vector drawing resources better in your own products. It's a shame that Expression Design can't import XAML after it is exported. A native XAML based drawing tool would be excellent if it existed but since it doesn't at least supporting SVG would be a great way to get people using vector based icons and graphics.

Answer 21

here are few things i would like to see in wpf5:

 

1. TextEffects working in FlowDocument and available on TextBox
2. mature Ribbon control, with inline galleries and normal comboboxes, that do not drop down over whole screen and behave like regular comboboxes. and yeah, adjust label width in a columns - it's really ugly when you add 3 comboboxes with different width labels...
3. provide real support for all Windows User Experience Interaction Guidelines, for example give us Task Dialogs without p/invoke
4. some kind of standard resource with all images required to make commands, not just cut/copy/paste icons, but all of commonly required icons. it's ridiculous to search in VS image library for an icon that looks like one from "Word" or "OneNote"... note, this includes necessary styles for task pane backgrounds, search box icons, etc.
5. search box control, with magnifying glass icon and all default behavior (dropdown menu with basic/custom options, intellisense when possible, etc.)
6. autocompletion & intellisense in any text based control with custom dictionaries or values providers
7. folder open dialog
8. rotation transform around center of the object, i just don't want to think of object sizes when i say "rotate it"
9. Undo/Redo framework with support where appropriate, it's 21st century and most of the applications do not have Undo - give it some momentum?
10. reordering drag and drop for items controls, just take a look as most of lists in MacOS X can reorder things, nice and clean animation makes the difference
11. some basic controls to do diagramming (i know Visio team will object though)
12. as mentioned before ObservableCollection should really have things like AddRange or Sort
13. interactive Popup controls, which got keyboard focus once they are activated?
14. better performance on graphics, i have noticeable performance down grade when i draw 1000 very long lines on canvas
15. Binding.StringFormat must assume we are producing a string, otherwise it's hard to use in any Content property
16. Visual Studio like docking panels, many UI can benefit from it
17. Matrix control that is similar to DataGrid, but have RowsSource, ColumnsSource and ValueProvider instead of ItemsSource property (and ofc it's gonna live with large matrices)
18. some sort of extension to the {Binding} that will be able to update bits from some [Flags] enum
19. more Effects, DropShadow and Blur is just not enough
20. better and concise docs, with less autogenerated spam or out-of-topic references and more internal mechanics description. It would be nice to have some sort of Properties/Fields table with default values specified, especially when it's BindsTwoWayByDefault on DependencyProperty.
21. some sort of {FileTypeIcon FileName='{Binding}', Extension='{Binding}', FileType='{Binding}', Size=32x32} - to extract current file type icon by file name, extension or registered file type
22. a <FolderView .../> control to integrate Windows Explorer into WPF out of the box

---

S.G.

Answer 22

With LoB applications I write I expect data input, validation and reporting.

I'd like more elegant validation.

Better support for MVMM and behaviours.  I want my items controls to expose behaviours like actions and commands without using someone else's code to add this on.  I shouldn't have to recommend Marlon Grech's ACB to anyone learning MVVM, the support should be there already.

I want View to viewmodel to database via entity framework ( or whatever ) to work smoothly without a shed load of plumbing.  Doesn't have to be drag and drop but it must not be rocket science and or a ream of code.

Support for WCF RIA would be nice.  Attributes generating validation?  Yum,

A native xaml reportviewer control is something that's obviously missing.  I want to build SSRS and Crystal reports and get the functionality I'm used to seeing in Winforms and asp.net.  Printing and reports are a big deal to most decision making managers.  It's what they do with systems.  They don't give one about h264 or drop shadows.  They want reports and more reports with better display and more collumns and drill down and...

Reporting is a big deal.  WHY are there no plans for a report viewer in the next version of WPF?

And no.  I can't use a third party control.  Most clients don't want third party controls because they remember the debacle they had with VB3 ones and dll hell.  They banned them back in the 90s and they're not about to change their minds.

Oh, and I agree with Sergey on icons.  It's all very well for a huge organisation to have a team of graphics designers available for your every need.  Others have to grind through the included zip file and try and find something appropriate.

Answer 23

After 3 years working with WPF... my biggest wish is a rendering performance boost. I want WPF to use the Hardware wherever possible, and to use it in the most efficient way so that we no longer have to consider other technologies when making something other than a LOB application.

 

I found an excellent article that explains this better than I possibly could here: http://jeremiahmorrill.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/

 

1. Transparent overlays on top of video grinds everything to a halt.

2. I'm not sure if this is a Media Player thing, or a codec issue... but playing H.264 Hi Def video is painfully jerky in the MediaElement and Media Player (but plays fine in vlc on the same machine), while re-encoding the File using MPEG Stream Clip (same res) using the Apple MPEG4 Compressor codec ensures that the video plays back smoothly. There are loads of other people out there facing the same issue.

3. The MediaElement control lacks a lot of extra functionality that would be really useful: 

     - The ability to grab frames on a frame by frame basis.

     - The ability to synchronise it with an animation in a simple way by handing it and the animation the same clock. The media player will lag behind the animation on large files when it loads, and stay out of sync

4. Deep Zoom! I've seen a lot of make do attempts, but nothing that is as smooth as the silverlight deep zoom. Believe it or not, there are many of us out there that want this. It's not just a "cool feature".

 

 

Answer 24

1. The lack of WCF RIA support caused me to leave WPF till further message.
   That's so essential having the validation attributes copied for you in the client with no hassle. also the DomainContext is a great tool that it's worth sufferring the other stuff SL lacks. I already got used to SL and don't plan to come back to WPF before RIA is implemented in it.
2. The other pain is the missing features and many features and controls not overlapping between WPF and SL. There should be a clear standard WPF, SL and SL for phone should always follow. Moving from WPF is pain in the @$$, in the other hand, as I said before WPF is missing the key feature SL has: RIA Services.
3. There should be out-the-box support and a clear standard for using MVVM, just like there is for MVC.

 

Answer 25

Better designer (goes without saying)....but not blend, our dev group hates it and avoids it.

WCF RIA services, why does WPF have to use plain WCF services, that's a marketing lead decision and it sticks in the throat.

Performance still has questionmarks

Debugging bindings (huge oversight), Silverlight gets XAML debugging but not WPF, again why tie one hand behind WPF's back

Built in MVVM support and a clear standard, it's a mess as it stands

Does MS intend to quitely drop WPF or roll it into Silverlight ?, there is no clear direction from Microsoft and it makes planning a solution with some reasonable future proofing very hard, I haven't forgotten the whole LINQ2SQL EF debacle.

 

 

Answer 26

@YAreAllTheDisplayNamesTaken

The MediaElement sucks, I had to write a video on demand system a while back and in the end we give up on MediaElement, we used up doing an Interop to MediaPlayer 1st and then VLC, hardly ideal but it worked reliably at least. I also implemented Digital TV playback, that as done using DirectShowLib and again a WFH host to a Usercontrol and was a nightmare.

You have to question why a technology so suited to Digital Media systems is so lacking in these areas.

I also did a digital signage app in WPF, no image transition effects out of the box in WPF, we ended up using Telerik WPF stuff.

Since I'm back in the world of business systems the WCF RIA services would be good.

Answer 27

all of the above.

---

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks

Answer 28

I see lots of good ideas here, from a lot of developers.

Definitely merge WPF and silverlight. It isd one of the reasons that we did an early move to WPF to begin with.

I agree that there should be a 1:1 for  WInForm/WPF controls, but most importantly, get the IDE to work as good as WinForms for RAD. This is one of the key advantages that .NET has (usually) been far superior to Java. I think that this is a failing of Microsoft anytime they come up with something new. They forget how easy things are to do in previous IDE's.

Answer 29

I've seen some terrific posts in this thread about ideas for WPF5, and I agree with all of them (to varying degrees of urgency).  But right now, there's a more pressing need - something WPF5 related that I'd really love to see. Something I'm getting a bit concerned about not having seen so far, in fact.

 

How about some indication of progress, Microsoft?  Are you still working on WPF5 or is it on the chopping block?  We've been waiting quite a long time now, and we're all eager.  In fact we've heard virtually nothing about the next release of the framework, let alone WPF or any other technologies that sit on top of it.  Oh, you've been working on Async methods?  Great.  Err... how about a Beta?  Even Silverlight, despite doom-mongers telling us that HTML5 will render it useless in Windows 8, has had a beta release, but us desktop developers just aren't worth your time any longer?  Heck, even a few blog posts from your developers telling us about some of the cool new features currently being worked on in .NET 5 would be reassuring, but months of silence is making us all wonder if we backed the wrong horse.  Remember, Microsoft - you can release all the fancy new Smartphones and Operating Systems that you want, but if you lose your developers it will all be for nought.  Throw us a bone here!

Answer 30

I have to echo Quanta's sentiment.

I'm at a crossroads in deciding what technology to support. We're heavily invested in WPF at the moment, and with the lack of progress / noise from the WPF team, we find ourselves at the point where we need to decide which technologies to move to over next few years. If we are going to stay with WPF, we need to have an idea what the roadmap looks like. We don't want to be building on a dinosaur for the next few years as our competitors leap frog us.

Since the release of 4.0 it has gone deathly quite, and that makes us nervous. If you are planning on letting WPF development slow to a grinding halt... how about a heads up so we can plan for it?

Answer 31

I concur, I've been building LOB applications for nearly four years with various flavors of WPF...nothing quite like your customers finding out their software is outdated before it's even completed - I would be furious to find out that Microsoft decided just to sweep it under the rug without letting us know well ahead of time.

---

If at first you don't succeed, skydiving is definitely not for you!

Answer 32

Does anyone here know if the WPF team still exists?

I am pretty sure that they do and I know that Microsoft is in lock down mode due to Build but it is like the team has been completely silent for some time.

If the XAML team was closed/moved around/reorganized I could imagine that the WPF team might be next in line. Maybe split the team into Visual Studio, Surface, Kinect and Expression Blend (if they exist) teams?

No matter what I am pretty sure there will be a WPF 5 because most if not all the code must be written by now.

Answer 33

There's a lot of people in the Silverlight team.

Have you seen the list of new stuff in SL5?

 

If they carry on at this rate SL will have more functionality than WPF before long.

 

Answer 34

I agree Andy. However the wellbeing of the Silverlight team says nothing about the WPF team.

<JOKE> Btw Silverlight is no more: http://www.youtube.com/watch?v=RRFiu0xfQzw&feature=share </JOKE>

Answer 35

MEK_DK, that was genious !

Genialt !

---

Developing is part of being a developer.

Answer 36

I agree Andy. However the wellbeing of the Silverlight team says nothing about the WPF team.

<JOKE> Btw Silverlight is no more: http://www.youtube.com/watch?v=RRFiu0xfQzw&feature=share </JOKE>

Indeed. The Silverlight team and WPF team are separate and will remain so for the foreseeable future, due to the fact that Silverlight really is a completely different animal despite the vast amount of shared syntax & capabilities.  Despite the (extremely humorous!) video above and the rather vague statements by MS just recently about HTML5 in Windows 8, Silverlight will definitely not die for a long time.  Microsoft have an enormous investment into WP7 and the primary (only?) development platform for that is of course Silverlight.  After the first abortive efforts MS made at creating a Smartphone platform, they can't really afford to fail again, and killing off Silverlight would ring the death knell for it.

Unfortunately they don't have the same obligations to WPF as they do to Silverlight, which is the main worry I have now.  With Silverlight getting all the attention right now and HTML5 getting all the attention for Windows.vNext, it doesn't leave many resources (or need?) for WPF.  Heck, it doesn't leave much of a requirement for .NET Desktop platforms of any kind.

Answer 37

Wishlist for WPF 5

1. To be released very very soon.

Answer 38

Hi

I suggest that the WPF team will work more on animations, I mean render animantions more smoothy so that the user doesn't detect interruptions when transformation happens

Reguards

---

The complexity resides in the simplicity Follow me at: http://smartssolutions.blogspot.com

Answer 39

Hi

I suggest that the WPF team will work more on animations, I mean render animantions more smoothy so that the user doesn't detect interruptions when transformation happens

Reguards

---

The complexity resides in the simplicity Follow me at: http://smartssolutions.blogspot.com

I wonder why XNA is not used to handle the graphics in WPF or SL. I would think there would be a WPF/SL layer on top of the XNA calls so WPF/SL developers don't have to worry about what version of XNA they are using. A WPF/SL developer can just make the XAML or WPF/SL API calls and it would work as expected fluidly.

Answer 40

I wonder why XNA is not used to handle the graphics in WPF or SL. I would think there would be a WPF/SL layer on top of the XNA calls so WPF/SL developers don't have to worry about what version of XNA they are using. A WPF/SL developer can just make the XAML or WPF/SL API calls and it would work as expected fluidly.

As far as I know, both Silverlight, WPF and XNA are just layers on top of DirectX anyway.

However, I wouldn't worry too much - looks like we all just need to start learning HTML5 and Javascript.  Because, ya know, those will be great platforms for writing desktop applications with.

On the plus side though, if we all go to fully HTML5 compliant applications we could eliminate the need for expensive Windows licenses - a lightweight freeware Linux distro with an HTML5 compatible browser would work just fine.  Nice business strategy there, Microsoft...

Answer 41

As far as I know, both Silverlight, WPF and XNA are just layers on top of DirectX anyway.

However, I wouldn't worry too much - looks like we all just need to start learning HTML5 and Javascript.  Because, ya know, those will be great platforms for writing desktop applications with.

On the plus side though, if we all go to fully HTML5 compliant applications we could eliminate the need for expensive Windows licenses - a lightweight freeware Linux distro with an HTML5 compatible browser would work just fine.  Nice business strategy there, Microsoft...

 

http://www.joelonsoftware.com/articles/APIWar.html

---

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks

Answer 42

Here's hoping that the reason everything's been so hush hush is due to tighter integration with the OS for Windows 8.  Maybe a bit more information will be released at the BUILD conference in September.

Answer 43

Well i dont think taht HTML 5 has even 50% of the capacity of the WPF/SL/XNA. Browsers have limits and one of them is that they cannot access the full performance of the machine, because of security measures and others. I personally really ap[rove the move of MS to not support WebGl in IE. This will be very big hole in the security and much more than typical spy bots can occure. Both browsrs and Desktops must live together and the developrs should always try to use the best suitable technology for the project needs.

I really hope that WPF 5 will bring even more included contorls. On the hand of the designers i have seen some packages with transactions and nice effects it will be nice microsoft to give some work in this direction. Also the VS can progress even more with understanding the xaml. I think that we had very big leap with moving from vs2008 to 2010 hope the next leap to be evein bigger.

Answer 44

Isn't this the place for feature suggestions?

http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions

Answer 45

Isn't this the place for feature suggestions?

http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions

Is it created/sanctioned/monitored my Microsoft?

Answer 46

A serius support for Multi-Monitor programming.

The wpf libraries has incomplete for multi monitor.

The .net 2.0 libraries are more complete but they often contains non-updated values in its structures.

the only way is to use p/invoke !!

---

Mr.Perelli

Answer 47

The point about having a WPF-counterpart of every WinForm control is actually critical to the success of WPF. While evaluating WPF as a plaform for developing internal business apps, I get asked this question a LOT:  "What made you decide to use WPF for this application?", and sure enough, i could usually come up with half a dozen reasons. But the next question i get asked is: How much money can it save us compared with WinForms? I'm actually quite scared by this one, as more often than not the answer is that it will cost more man-hours. Decision makers are not usually convinced that the benefit of WPF's bells-n-whistles justifies this additonal cost.

I know WPF consultants (whose livelihood depends on customers moving to new technologies) would point out that with WPF it's much easier to create custom UI than WinForms/Win32, but the truth is that seasoned Winforms/win32 developers already know how to pull off most of the magic (there are hundreds of well-known working examples on the web/MSDN) and switching to WPF results in zero cost-reduction (if not a huge cost increase).

Contrast this situation with when Winforms was introduced in 2002, it was very clear to everyone that WinFOrms was a cleaner & easier to use technology than VB6/MFC.

 

Bottomline, MS has to prove to everyone that WPF is better AND easier to use than the technology it wants to replace.

Answer 48

the future of windows development ...

http://msdn.microsoft.com/en-us/windows/home/

and a PDF guide ...

http://download.microsoft.com/download/1/E/4/1E455D53-C382-4A39-BA73-55413F183333/Windows_Developer_Preview-Windows8_guide.pdf

Seems like WPF is getting a backseat to the triumvirate of WinRT, XAML and C# ... at least my C# and XAML skills will come in handy.

The slide featured on this piece here is also very interesting:
http://www.readwriteweb.com/hack/2011/09/build-2011-what-is-winrt-and-i.php

Answer 49

Some kind of native ObservableDictionary classes with the proper notifications for changes on keys and values.

And Visual Studio more oriented for the development in a MVVM way.

Answer 50

Overall performance improvements are always welcomed.

• Better startup performance, a Flashscreen implemented completely in native code, without having to load .net bits will be good.
• Better performance for animations.
• "WPF client profile' a subset of .net which only contains WPF api and no bloat from winForms etc. If this can be under 10mb then we have won!

 

---

Sameer V.

Answer 51

Some kind of native ObservableDictionary classes with the proper notifications for changes on keys and values.

And Visual Studio more oriented for the development in a MVVM way.

There's already Dr WPF's observabledictionary.

The application which I've used that, I'm probably going to change to using ICustomTypeProvider instead.

Answer 52

Better rendering support for many small objects. I love wpf but because I need to render hundreds of thousands of objects I cannot use it. Most are off screen and do not need to take any cpu. A sort of quad tree should be used to only render those that require it.

 

The problem with visual tree as it stands is every object is tested and every event is passed even when many cannot participate in the rendering and event handling because they are completely off screen. By pruning this tree it can drastically increase performance. A quad tree can efficiently deal with display and event handling.

 

There are hacks and work arounds but they break wpf for the most part and are still slower than old school.

 

Answer 53

I don’t have a huge investment in WPF, so I will speak from the point of view of someone potentially evaluating it for new products. In terms of my ability to recommend WPF for any new product development, I would say it’s a long-shot in its current state. This has nothing to do with what features it has, and everything to do with how different it is from the WinRT XAML stack (currently the only Microsoft UI stack usable from .NET with a clearly sanctioned future). I can't justify choosing WPF for any new product NOW when I know that 1) The app will never make it onto the windows store, 2) the app will never make it onto Windows RT in any form, and 3) The majority of the UI related code written for WPF is not readily portable to WinRT's XAML engine.

I think Microsoft really needs to focus all of their attention on one core UI stack, and build onto that core UI stack experiences tailored for different devices and modes. So, here is my recommendation for WPF:

• Kill WPF. After the next major release, put it on extended support for another 6 years or so with only minor updates for bugs/security/OS compatibility. During that time, begin porting over functionality from WPF into WinRT's XAML stack as needed, and:
• Create a new “Desktop Mode” for WinRT apps. This desktop mode would allow regular Metro style apps to switch to a “desktop mode” or back to “fullscreen mode” in the SAME app (SAME binary and same windows store entry, not a different app with a different “profile”) and allow the app to freely switch between the two while running.
• Have an app manifest setting to indicate that the app should start in desktop mode initially, rather than full-screen mode.
• DON’T add functionality that is exclusive to the desktop mode that could be useful for full-screen mode. The core WinRT API should be the same between the two modes, allowing a single app to support switching between both modes. Features that are only available in Desktop mode, such as creating multiple windows, would require you to switch to desktop mode first, or else throw an exception.
• DON’T add ANY CONTROLS  or XAML features (like custom binding extensions) that only work in the desktop mode. ALL controls and core XAML functionality should be available in either mode. You may add functionality that is specific to the desktop app environment, such as the ability to create multiple windows, floating windows, etc… And you can re-style controls while in the desktop mode vs the full-screen mode, but no missing controls. We should be able to freely share controls, data templates, and various views between the desktop mode and the touch mode and merely tailor the layout/navigation to the current mode. For instance, you could port the WPF FlowDocument functionality to WinRT, but do it for both full-screen and desktop mode, even though the FlowDocument typically represents "producer" app functionality vs. "consumer" app functionality.
• Like pinning secondary tiles, the user should always be in control of when an app switches to the desktop mode. The API for switching to desktop mode should be similar to how you pin secondary tiles - app code makes a request to switch to desktop mode, then the OS presents the user with a dismissable popup asking for permission to switch. This popup should have a checkbox to remember this decision and allow the app to switch modes in the future without permission. This checkbox should correspond to a setting in the Permissions section of the settings tab for the app so they can change their mind later.
• Allow these desktop-profile WinRT apps to be distributed through the store, or via a private corporate app store, just like other metro apps.
• Allow these desktop-mode WinRT apps to run on Windows RT.

Answer 54

Nice closing words SleppyDaddySoftware! :)

Answer 55

Better rendering support for many small objects. I love wpf but because I need to render hundreds of thousands of objects I cannot use it. Most are off screen and do not need to take any cpu. A sort of quad tree should be used to only render those that require it.

The problem with visual tree as it stands is every object is tested and every event is passed even when many cannot participate in the rendering and event handling because they are completely off screen. By pruning this tree it can drastically increase performance. A quad tree can efficiently deal with display and event handling.

Hmm... it makes me wonder whether WinRT would have similar issues...

Answer 56

As someone recently started creating apps in WPF can I add to the call for ALL of the winforms controls to be in WPF 5 in some format. I have a multitude of different screen sizes and windows OS for my apps to run on in my company (and the same scenario at previous companies) so WPF makes sense to fix the layout problem, only every time I try to port an app I find a control missing. This is not acceptable for a mature enviroment and paying a third party for some controls is not the way forward, no company i work for is prepared to do this. Once this is done all my and my teams development will be WPF and then we can look at silverlight for web development due to minumum cross over costs. Finally VS needs more of the basic functionality of Expression, I should not need two tools to develop an app, if a basic tutorial suggest the need for two tools then there is something wrong. I have never worked anywhere where an app has a graphic designer for its look and feel, its always been the programmer that does it, and I just want to open VS to do it, not double my costs to have another tool.

Answer 57

You get Blend with VS2012.

The bad news is when you look at the templates in it, you won't see WPF or Silverlight.  AFAIK that just stops you creating new projects but the writing is there on the wall.

My guess is that WPF won't be getting many more features.

Answer 58

So WPF is dieing before adulthood? How sad... I wish they'd have made it work properly in 6 years, so at least we'd know WPF's full bloom and we'd be able to decide if WPF was a good or stupid technology. Now it will be forever known only as a stupid decision.

Answer 59

I think WPF works pretty well at the moment.

SP1 added WPF and Silverlight templates to Blend 2012.

What's unclear ( and may not have been decided by MS ) is whether WPF is truly sidelined with future development reserved for windows store apps... or whether it might get a reprieve.

Maybe we'll hear more from Build next month.

Maybe not.

So far enterprises have been noticeably unenthusiastic about the metro side of Win 8.  It is of course possible that MS will realise metro is not so great for desktop computers and they better not alienate corporate users any more.

.

As to MJP9 and wanting all winforms controls in WPF.

I've done both and there's nothing I particularly miss in WPF.

WPF controls are lookless.

Same goes for all XAML controls and hence windows 8 apps.

You can make them behave in ways that you'd never imagine coming from a winforms background.

There isn't a need for a number of the winforms controls, because you can make a usercontrol do that or style an existing control like that.

A report viewer is one particularly noticeable exception.

Available from SAP as a free download, together with crystal reports.

Answer 60

BUMP and BUMP again.

I would like an update on this if at all possible either this or Win8 Apps that can run outside of the Windows Store.

Desktop and enterprise desktop developers need something from Microsoft and tbh with you; killing Silverlight and no announcements on WPF is unacceptable imho.

Answer 61

Actually SleepDad,

MSFT should Kill WinRT and pull together all this disparate and ridiculous parts into one time one place that works for everyone.  The concept that a phone GUI drove the OS into the ground is absurd.  MSFT made a huge mistake here, and should have followed the Java model which they started but abandoned.  The Java model is simple, the is the real Java and there is the client Java.  But the bottom line is Java is Java.  Windows is NOT WinRT.

MSFT should finish what they do before they do anything new.  This system is one kludge after another.  And they don't care. 

WPF=WebBrowser Airspace issues, no C# wrappers, Office Interop is ridiculous.  C# can not contain Win32 Windows easily and some not at all.  WPF RTB should be ubiquitous but it not, it lacks function. Windows 8.1 is the worst software ever released by MSFT.

As for our good friends in C# lab, they're the bright spot at MSFT, C# is a killer language and these boys do it right.

---

JP Cowboy Coders Unite!

Answer 62

Recently we had a large group of new team members join us having come from a major player in the industry.  We are a MSFT shop but they came for a Java shop.  Isn't it ironic that SUN died but left the JAVA legacy that has eclipsed C# in popularity?  But one might ask why?  Java never had anything like WPF.  As it turned out, many in the Java world learned how to use web browsers instead of windows.  Java + Web Browser bypassed the elegance of WPF in ease of use and maintainability.  But for those of us who love C# and WPF, all of a sudden we're left in the board rooms acting like spoiled kids fighting for our favorite platform.  Thanks a lot MSFT for throwing us under the bus.

C# is still my personal favorite, but... the winds are a blowin' out here in the sea of ideas and decision makers.  I personally would never abandon C# and WPF, but my bosses could easily toss it.

---

JP Cowboy Coders Unite!

Answer 63

bump !

Answer 64

bump !

Answer 65

microsoft topped the tree , and left xna and wpf laying on the ground ...
if winRT is supposed to be a win32 replacement , then microsoft needs to graft MFC , XNA , and WPF back onto the stack , and finish porting Dx12 to managed while they're at it .

If we have to learn new APIs , we might as well learn ones where microsoft can't do this again .

Answer 66

MSFT's new silence policy is deafening to me.  After many years of my complaining I finally threw in the towel for WPF knowing I can use it for anything I want in the future; but, things like JQuery, Knockout and Angular are going to allow web browser apps the power of WPF.  Unfortunately, while XAML and WPF are superior in my opinion, the DOM is king.  Too bad MSFT couldn't give JQUERY a run for the money implementing WPF and XAML concepts.  The problem with JQUERY is that it's built on the non-reflective Javascript object model.  This makes browser based development stone-age in effort and foists the control of the programmer onto how the browser operates, not what the user intended.  

MSFT's lunch was being eaten by the web browser world and they capitulated to it saying things like this at their own ALM conferences "Embrace open source" "try to outsource" Hey maybe that's what they'll do, outsource WPF?

 

---

JP Cowboy Coders Unite!