Desktop apps: WPF 4.5 and Visual Studio 2012

Play Desktop apps: WPF 4.5 and Visual Studio 2012
Sign in to queue


WPF is a great technology to use to build desktop apps for Windows. WPF 4.5, .NET 4.5, and Visual Studio 2012 include a number of targeted enhancements requested by our customers building data-intensive ISV and line-of-business apps in WPF, and for those who wish to share code with Modern apps for Windows 8. In this session, we'll demonstrate a number of the new features you can begin using today.






B92 Odyssey



The Discussion

  • User profile image

    That DJ joke at 37:20 in the binding delay context was funny.

    But what is going on in VS2010 and VS2012 that when you scroll the code using the scroll bar, it stops updating momentarily if you scroll it too fast. That makes the products feel inferior to VS2008, nevermind the fact that if you don't have everything on SSD that VS2010/2012 access, they're going to start up slower than VS2008 from a HDD.

    These two issues are key reasons why I have not bothered to learn WPF after finding that they are more rule than exception in WPF apps compared to previous technologies. IMO it's not worth bothering with WPF until the issues which makes your product feel inferior within timeframe of the users first impression are solved, if they can be.

    If MS hasn't been able to solve such issues in their flagship product it just cements my belief that WPF & .NET have still unsolved fundamental perf issues and product made with them cannot compete with same product done in Apple's development technologies when it comes to the critical first impression.

    To everyones dismay, it would seem the long cold launch time issue has migrated to WinRT. Even on a high end desktop launching stuff from SSD, the Metro app startup times are unacceptable and professional journalists have pointed this out as a major issue. The result of this is that I haven't bothered to look at learning WinRT either until there's some proof that MS can solve this for the scenario where user installs an application and runs it for the first time, the "first impression run". The target for this should be <300 ms rather than 10 seconds that the journalists quoted. I can't remember any application in my 486 DOS days that took even 1 second to start from HDD! And those apps were much more complex than anything I've seen Microsoft ship with Windows 8. In 300 ms you can download and execute some darn complex DOS apps that fit on a floppy or two and haven't been surpassed to date. Example: Elite 3 game.

    There is a technical solution to this though, instead of downloading Modern apps and cold running them, download a delta compressed memory image where the base for the delta is a blank running Modern/NET app and start executing it progessively during download. Just NGEN is not enough when it comes to WPF bloat.

    The "bound scroll bar" performance issues should be solvable with caching on background thread if there's no other solution, there's no technical reason why "scratching" the VS2010,2012 code editor scroll bars should have any dips below 60 FPS.



  • User profile image

    Just a nitpick. Maybe there's a reason behind that but it irks me when presenters do "right click  -> resolve > using .." rather than ctrl+. [enter] to resolve namespaces (add usings).

    I think this teaches the audience of a very inefficient way to work as a developer (though I hope the audience already knows the faster way).

    Other than that, good session, thanks!

  • User profile image


    There's more than one way to do just any given task. I tend to use the mouse. There's nothing wrong with that nor anything inherently cooler about remembering the key combinations Smiley


  • User profile image

    BTW, the dialog sizing issue at 0:27:00 or so is not just because I'm at 1366x768, but also because I'm running at high DPI. I forgot that my laptop is 125%, so I was actually getting less than 768 in height -- not a typical scenario.

  • User profile image

    I've not watched the video yet, just flipped through the slides, but...

    Is there any way to synchronize access with a collection that uses something other than a basic lock on an object?

    We use ReaderWriterLocks on all of ours (as reads happen a lot but writes are pretty rare). At the moment we also have to maintain a read-only ObservableCollection that is modified on the UI thread whenever the underlying collection is changed (and the writer lock released). That's the one we give to WPF for binding.

  • User profile image

    @swythan I mention that in the talk. You can go with a callback approach if you'd like.

  • User profile image

    Fantastic. I promise I'll actually watch the talk soon!

  • User profile image
    Amalendu Dey

    You can also refer to the link below instead

Add Your 2 Cents