What are some good WPF resources?



  • I'm a C#.Net developer and I have a basic idea of of what WPF is and did a few basic things with it.
    But now I would like to get into it indepth and do some advanced stuff.

    I'd appreciate if you could give me some links or names of books that help.

    Cheers!



  • Start a project. Google for stuff you don't know.

    No book comes even close to actually working with whatever you want to learn.


  • :belt_onion:

    I agree with above. I learned most of the stuff I know by doing and googling / reading docs as I got stuck on something.

    If you don't have a big project in mind, or just want to learn the basics real fast, I'd recommend something small you can finish quickly. Something like a simple notepad app, for example.



  • I always keep this bookmarked because I forget binding syntax for collections all the time. I find it is a good lookup reference.



  • Slightly OT: Is WPF still relevant? Seems MS has given up on it. It's not getting ported to Common CLR. It's not getting many updates either.

    Also, in this day & age, doing stuff in Windows-only framework seems kind of pointless.

    I was hoping MS would update WPF to be cross platform, or extend their modern apps framework to be more desktop / multi-platform friendly. But so far, no luck.


  • sockdevs

    A lot of WPF techniques and knowledge applies equally well to Silverlight and WinRT, the latter of which is what Microsoft appear to be moving focus too.



  • @RaceProUK said:

    A lot of WPF techniques and knowledge applies equally well to Silverlight and WinRT, the latter of which is what Microsoft appear to be moving focus too.

    Yeah, that's the problem. Silverlight is dead and WinRT is limited to the godawful "Windows Store App" paradigm. I've been waiting for a proper successor to WPF for years now, but still nothing.



  • @cartman82 said:

    Also, in this day & age, doing stuff in Windows-only framework seems kind of pointless.

    Why? Most developers work in corporate environments and Windows is on almost all of their desktops. Think of it like RPG and COBOL development. It's not new and shiny, but there is a ton of demand for it.

    If you are building your Windows apps properly, add a Web-facing component or a mobile app should only involve building a UI. 80% of your work can be re-used.



  • @Jaime said:

    Why? Most developers work in corporate environments and Windows is on almost all of their desktops. Think of it like RPG and COBOL development. It's not new and shiny, but there is a ton of demand for it.

    If you're in a corporate environment, WPF seems like an overkill. Most of the stuff done there can be better achieved through some kind of web interface.

    With all its fancy widgets and features, WPF cries to be unleashed in some really nice user-friendly desktop app, targeting a wide audience. Unfortunately, that kind of target market is becoming less feasible year by year.

    @Jaime said:

    If you are building your Windows apps properly, add a Web-facing component or a mobile app should only involve building a UI. 80% of your work can be re-used.

    That still leave the question what if you want to go multiple desktops (Windows, OS X, Linux Desktop), instead of multiple MS environments (Windows, ASP.NET web site, MS app store). Microsoft is promising a solution to expand the later (with Android and iOS support), but not the former. At least as far as I've heard.



  • @Jaime said:

    Why? Most developers work in corporate environments and Windows is on almost all of their desktops

    In that case, you're better off with WinForms. Sure, its quick and dirty, but that's an environment where quick is a huge asset and dirty doesn't matter much.

    Unless your corp does something like 3d modeling or something else way outside WinForms competence.



  • @cartman82 said:

    That still leave the question what if you want to go multiple desktops (Windows, OS X, Linux Desktop),

    For corporate users, no biggie. Either require non-Windows clients to run a Windows VM, or use Citrix, App-V, or RDS to deliver them the application.

    @cartman82 said:

    If you're in a corporate environment, WPF seems like an overkill. Most of the stuff done there can be better achieved through some kind of web interface.

    The web is a lowest-common denominator solution, not a best-of-breed solution. Web apps are not as good as desktop apps and they take longer to write and debug. Also, web apps decay. Very few web apps written five years ago (and untouched since then) work on modern browsers. Most Windows apps from 20 years ago still work fine today.



  • @blakeyrat said:

    In that case, you're better off with WinForms.

    As ugly as they are, yeah. There's just so fucking much boilerplate in WPF, so many abstract concepts, that it's really not worth it unless the interface actually is a priority.



  • @cartman82 said:

    Slightly OT: Is WPF still relevant? Seems MS has given up on it. It's not getting ported to Common CLR. It's not getting many updates either.

    It's too deeply connected to Windows for them to easily port, probably, but I think they'd also prefer people use their own platform's UI libs. Besides, it did get updated this year.

    @cartman82 said:

    WinRT is limited to the godawful "Windows Store App" paradigm.

    You mean the one where your app is inside a normal window, and uses device-independant pixels rather than real pixels? What exactly do you think you're referring to?

    @Maciejasjmj said:

    As ugly as they are, yeah. There's just so fucking much boilerplate in WPF, so many abstract concepts, that it's really not worth it unless the interface actually is a priority.

    Not sure which boilerplate you mean, unless you mean closing tags in XAML. WPF can be simpler than winforms, depending on how you're going about things.



  • @blakeyrat said:

    In that case, you're better off with WinForms. Sure, its quick and dirty, but that's an environment where quick is a huge asset and dirty doesn't matter much.

    Unless your corp does something like 3d modeling or something else way outside WinForms competence.

    You can use WPF pretty much the same way as WinForms. WPF just gives you an option to get fancy if you want.

    On the other hand, WinForms components do have much more bells & whistles out of the box than WPF (which encourages you to extend and "make interface your own"). That can be a big win in a quick & dirty scenario.

    @Magus said:

    You mean the one where your app is inside a normal window, and uses device-independant pixels rather than real pixels? What exactly do you think you're referring to?

    Limited to "metro" interface (which is better now than it used to be back in the Win8 days, but still not perfect), reduced feature set (removed all "dangerous" API-s from .NET), having to distribute the app through Windows Store (a dealbreaker for me)...

    Can you even have a direct HDD access from an App Store app? The last time I checked, it was an iffy proposition.



  • I have to say I really like WPF - and looking at where MS are going, it's quite possible that whatever the new desktop technology is going to be will re-use a lot of concepts from it. That said, I am miffed about the lack of significant development in this area

    @Maciejasjmj said:

    There's just so fucking much boilerplate in WPF,

    Huh? Other than property change notifications and some kind of delegate command base type (which I believe any framework provides out of the box these days and that you can easily knock out once in a reusable library) I can't really think of any essential boilerplate.

    @Maciejasjmj said:

    so many abstract concepts,

    It does take some getting used to, true. I wouldn't call the ideas abstract, but the WPF philosophy is markedly different than WinForms, say. I actually find this to be a bonus.


  • sockdevs

    @GOG said:

    Huh? Other than property change notifications and some kind of delegate command base type (which I believe any framework provides out of the box these days and that you can easily knock out once in a reusable library) I can't really think of any essential boilerplate.

    Maybe not in the codebehind, but have you seen the verbosity of XAML?



  • My main project at work uses WPF.

    XAML is one of the reasons I like WPF. I've most of the presentation stuff set up as resources, so I'm mostly doing either arrangement (grids and panels) or setting up data bindings. Creating views is the least time-consuming task for me.



  • Oh hey, look who's back.

    And I still think doing WPF the "proper" way (command objects, viewmodels, etc, etc) is somewhat painful. It's a powerful tool, that's for sure, but really unsuited for RAD-style "throw some GUI together" apps.

    A bigger project will certainly benefit from it, though. But as I said, it'd have to be at least somewhat UI-centric to actually use the capabilities.



  • Valid concerns, to be sure.

    I find that for the kind of project I'm doing, it actually saves me a world of hurt, because it allows me to reuse just about everything. Mind you, this is a project that has grown considerably (and organically) over the past two years or so and I've no idea where it will be tomorrow1, despite my boss always going on about a feature-freeze - just before requesting a new feature. :smile:


    1 Same place as today, I'd wager, 'coz tomorrow is April 30th, AKA personal income tax deadline.



  • @GOG said:

    April 30th, AKA personal income tax deadline.

    If you have to care about this date, you're either a tax clerk or you're doing your taxes very, very wrong.



  • The cobbler goes barefoot, no?

    Actually, I already received my rebate. I do know some folks at the firm still haven't done theirs.

    Yes, I do work in accounting/taxes. This year I've mostly managed to dodge tax season (this may be due to hiding in a dark corner next to HR), but tomorrow is a day to expect the unexpected.



  • @GOG said:

    This year I've mostly managed to dodge tax season

    Mine was easy this year, got a payslip and worked off that. Next years' taxes will have to involve TDWTF writing earnings too, and that's probably gonna be a world of hurt...



  • @Maciejasjmj said:

    Next years' taxes will have to involve TDWTF writing earnings too, and that's probably gonna be a world of hurt...

    Having spent an hour or so trying to establish the correct amount of earnings from Germany a client should declare, I can only say: "Yep, probably."



  • I...actually just wanted a few resources...
    MathNerd, thanks a lot for the link.
    To know what I want to do, I need to know what I can do, so a tutorial or book of sorts guiding me is important.

    Anyway, I saw a job ad that looks interesting which fits me perfectly except the requirement of WPF.



  • @UnknownDev said:

    I need to know what I can do

    The only limit is your imagination.

    More seriously, if you "did a few basic things with it", you probably have a grip on what it's for. And that's enough to make a small best-practices project.



  • The best I could thing of is a data driven application that has some of fancy images and shows some movies in places winform wouldn't allow them.

    Like, maybe some kind of small movie database that shows the movie trailer in background while you set some values in the foreground (how many times watched, personal rating and comment, etc.).

    But I don't think that's all WPF can do nor all people usually use it for (or for that matter Silverlight if it replaced WPF now).



  • For my final school project, I made a simple vector drawing app. That was pretty WPF-y.



  • This post is deleted!


  • @Maciejasjmj said:

    really not worth it unless the interface actually is a priority.

    If you just want to throw primitive data on the screen, then yes winforms is better.

    If you need complex viewmodel interactions, like multiple ways to view the same data, then wpf is much better. Much much better.

    Once you define a viewmodel, you can give it any number of views, and attach it to the same data.

    Try doing that in winforms. You'll have to break the data down into primitives designed specifically for that view, or exchange the data into separate viewmodels designed for each view.

    Winforms
    Want to change how a value is displayed, create a method to convert the data into the control, call that method everywhere in the code behind. Or create a property. Have to add code to every viewmodel that needs that conversion.

    WPF
    Want to change how a value is displayed, create a converter, throw that in the binding, can be reused for datagrid on demand. Converter can be reused in different viewmodels too, without adding anything to those viewmodels.



  • "What are some good WPF resources?"

    Me. Been doing it for 4 years.

    Make the move into viewmodels.

    All you need is a class that uses INotifyPropertyChanged, and use ObservableCollections for hierarchical data.
    For commands look up Relay command.

    Then derive from that for every viewmodel.

    I have a base viewmodel class that throws everything into a dictionary. Then supplies GetValue<T>([CallerMemberName] string propertyName = null), and SetValue<T>(T value, [CallerMemberName] string propertyName = null).
    SetValue triggers the PropertyChanged event.

    With that, all the complexity of dependency properties is gone.

    IMO dependency properties should be reserved for Controls anyway. That's the only place you need inheritance and attached properties anyway.

    You give each viewmodel a view as a DataTemplate
    Then whenever you have a viewmodel that references another viewmodel, you just add a container control in your view. If it's a list of child viewmodels, you use the appropriate itemscontrol and set its itemssource to the observablecollection.

    At that point, you have a toplevel view that attaches to the top level viewmodel, and the interface will build itself.

    If your viewmodel has a command, implement it as a relaycommand and add the appropriate docommand and candocommand methods.

    If you viewmodel has a container of commands, implement it as a observablecollection if the list ever changes or a simply IEnumerable if the list of commands never changes. Throw that in an itemscontrol like menu. And now you have a view that can consume a list of commands dynamically. You'll never need to change the interface again for commands, you simply add a new command and command methods to your viewmodel.

    If you ever need a different view for the same viewmodel (like you want to add a small status bar or you want to add a view for a listcontrol that only shows a few uneditable properties so people can browse records), then you only need to add a new datatemplate but give it a named key. Then have your list control consume the list of record viewmodels, and reference the keyed datatemplate explicitly.



  • Have a look at Microsoft Patterns & practices - PRISM

    Here: https://msdn.microsoft.com/en-us/library/gg406140.aspx

    One of the key things I have found with WPF, much more so than with WinForms, is that resources for solving problems focus far more on doing it right than getting it done. If you want to use WPF you probably ought to get used to MVVM, because any software house you will want to work for that uses WPF will be using it.

    getting your head around PRISM is extremely useful as a guide to doing things completely unrelated to it. Understanding how you can loosely couple everything in your application and still come out with something that fits together seamlessly is a big challenge, and PRISM shows you ways it can be done, and that's really useful to learn, even if you end up not using it.

    The key things to know about WPF are data bindings and data templates, this is where WPF most differs from WinForms out of the box. In WinForms your code specifies what your controls display. e.g. textbox1.Text = "Foo" whereas in WPF your controls specify what data they are going to look for. e.g. <TextBox Text="{Binding Foo}">. Similarly, in WinForms you can either display complex data in a grid/table type format, or you can create a usercontrol for displaying that data, then check your collection and create X user controls one for each object. WPF takes care of all of this by letting you bind a data template (your display for each item) to colleciton objects like ListViews, letting you display your data exactly how you want and specify it entirely in your UI rather than in your code.

    This separation is all possible with WinForms, but it isn't the behaviour that is encouraged by the technology. That's the difference between the 2.



  • The best thing PRISM provides is the DelegateCommand, and it's not hard to roll your own there.

    You can do a similar thing with their version of events, and [Import] your own around the application, rather than using their stupid service locator EventAggregator.

    But like you said, it gives you some direction.

    I probably wouldn't have discovered MEF if we hadn't been using PRISM at Intel, and I wouldn't want to do MVVM without it!


  • mod

    @blakeyrat said:

    n that case, you're better off with WinForms. Sure, its quick and dirty, but that's an environment where quick is a huge asset and dirty doesn't matter much.

    Unless your corp does something like 3d modeling or something else way outside WinForms competence.

    I've found WPF makes multi-threading a lot easier than WinForms. Comes in handy mostly when you've got a long running process and want to keep the user informed of the ongoing progress. Try to do that in WinForms and the UI thread hangs waiting for the worker to finish it's job, unless you do some heavy work to get the asynch working right.



  • The BackgroundWorker control does all the threading work for you, there is no code. I've done it before the days of BackgroundWorker and it was only about five lines of code to get the progress data back to the UI thread.


  • mod

    Ah, when I first got into this kind of thing, I was trying to find info on that, but one as having a bad day. WPF multi-threading came to me much easier. The multi-threading in WPF make cross thread communication easy, so that I can update any control from any thread with ease.



  • @abarker said:

    Try to do that in WinForms and the UI thread hangs waiting for the worker to finish it's job, unless you do some heavy work to get the asynch working right.

    Heavy work? Just add a BackgroundWorker class. It couldn't be simpler.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.