Opinions on WPF (.NET 3.5)

[AJ]

Hi,

As well as hobby OS Dev, I also use C# to write Windows Apps. My current project is a Practice Management System for my Optometric Practice which has a C# front end to an SQL database.

I have just gone over to .NET 3.5 and have started playing with WPF instead of Windows Forms. I would be interested to hear from any other Windows developers (particularly professional coders) about what the current opinion of WPF is in "the industry". IS WPF set to take over completely from Windows Forms? Any particular likes/dislikes about the way MS have implemented the interface between C# and XAML? For speed, should I avoid WPF altogether. Most of the articles I have seen are quite in favour of WPF but then they are probably based on MS press releases and it would be good to hear from anyonw with practical experience.

I'm thinking of designing this Management application using WPF but am trying to get my head around some new concepts at the moment - it may be that using WPF will turn out to be just like using Windows Forms and I am just making a fuss about nothing.

Cheers,
Adam

[AndrewAPrice]

I've used WPF a tiny bit, but I'm no professional at it. The main difference I noticed is that the window's layout is defined in their weird XML language instead of in auto-generated C# code, oh and all the WPF components are rendered using D3D (which doesn't really matter since I heard the entire Vista window manager (or was it just Aero?) now uses D3D).

As far as speed is concerned, I don't really know enough to give you an exact answer. I doubt it'd make much of a difference except when loading a component since it has to parse the XAML file (perhaps it does it at compile time, but I never checked).

I'm sticking with Windows Forms for my GUI needs. Why? Because I know how it works, it does everything I need to, and I'm more comfortable with the designer and code it generates. And I have yet discovered a reason to use WPF because I'm not making a program with a WMP/Winamp interface or anything which requires fancy scalable vector graphics (and if I did I would mix it in with forms and just use WPF for the graphs and such).

[DeletedAccount]

I'm sticking with Windows Forms for my GUI needs. Why? Because I know how it works, it does everything I need to, and I'm more comfortable with the designer and code it generates. And I have yet discovered a reason to use WPF because I'm not making a program with a WMP/Winamp interface or anything which requires fancy scalable vector graphics (and if I did I would mix it in with forms and just use WPF for the graphs and such).

Have you used threads with Windows Forms , I havent used WPF for anything -- but i know the Windows Forms does have problems and it is sometimes difficult to track the bug

[Troy Martin]

Windows Forms > WPF, 100%. Not only does it let slightly older versions of windows use your apps (does 98 even support .NET 3.x?)

Anyone else other than me think that .NET stands for "No Extra Technologies"?

[albeva]

Last time I used WPF I noticed that it rendered rather ugly graphics - especially ugly wierdly antialiased fonts. Have they fixed that now? General perfomance wasn't too goood either as I remember. But it was during beta.

[AJ]

Thanks for the opinions. As I am already pretty familiar with Windows Forms, it looks like the concensus at the moment is not to bother with WPF. Of course, I'll be trying to keep the frontend and internals as independent as possible so if in the future I want to "port"...

Cheers,
Adam

[mystran]

Am I missing something when I'm still writing my Windows GUI code against the Win32 C-API?

That's possibly the most beautiful design ever, once you get below the slight surface syntax ugliness. Anything else I've seen (which would be not just the .NET options but also pretty much every toolkit you can find on freshmeat, unless there's some new gem in the last 2 years or so) is absolutely crap compared to the beautiful Smalltalkish, runtime extensible, plugin friendly, trivially wrappable Win32.

[amn]

It is not the beauty of Win32 API that appeals to you, it is the fact that it is so relatively low-level, like LEGO, it lets you create your own frameworks and does not limit your freedom of program expression. Win32 is Windows' assembler language, the closest and lowest you would get talking to Windows. Even the assembler assemblers, like the most famous macro assembler tools for Windows use Win32 bindings. Whole Windows is a bunch of DLLs anyway. Everything is built on top of Win32 API, even .NET. So if it will go away, there is no way back. There is of course the DirectX API next to Win32 API, but thats another discussion.

When you use WPF and want anti-aliased fonts, you have to trigger a variable switch for that first.

[mystran]

It is not the beauty of Win32 API that appeals to you, it is the fact that it is so relatively low-level, like LEGO, it lets you create your own frameworks and does not limit your freedom of program expression.

That is exactly the beauty of it. By trying to oversimplify GUI programming, most toolkits just make it unnecessarily complicated, especially if you ever want to structure your code in a way that the original toolkit designed didn't think of.

I think for most purposes frameworks are unnecessary bloat anyway, and often just complicate things. Good general purpose libraries that don't limit your design choices, are IMHO much more useful. Unfortunately they are also a lot more difficult to design, so you see tons of "one way to do it" style toolkits instead. I guess those are great, if you want to do exactly the thing that the toolkit was designed for. Personally though, I find myself all too often wanting to do more, or slightly different.

Oh, and then there's also the thing that I hate about toolkits the most: when you have a toolkit, with bugs or limitations built into the toolkit itself, your often pretty much stuck, unable to fix it, because after all, the typical toolkit was designed to hide the low-level details: the details that are necessary to get your component to do the thing that wasn't implemented properly in the toolkit.