8

Actually, I have started learning WPF. I have few months of experience in developing Windows Forms applications. Though, I am getting the meaning of a WPF application, but still I am not able to differentiate the difference between two, on the basis of their output.

With reference to this Link: Device Independent Pixel (DPI), I have learnt that whenever the operating system render a WPF application it manages its size itself according to its resolution.

So to check this difference, I created two demo applications in both frameworks and changed the resolutions as well.. but I didn't find any satisfactory difference. Which could explain it is a WPF application and this one is a Windows Forms application.

It does not create any scroll bar on maximizing and doesn't make the button big or small on changing the resolution.

I have read somewhere that Visual Studio 2010 has been rewritten in WPF. But in my experimentation I saw that, (on changing the resolution of desktop) it makes text and graphics unreadable/blurry. On re-sizing its window, everything was getting hidden except the menu-bar. And the menu-bar content was shifting its positioning, e.g. far right one menu items were shifting down. Why?

Kindly make me correct & explain a little more bit (this display issue) too.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user2804762
  • 81
  • 1
  • 1
  • 3
  • I have no idea what you're talking about. WPF is resolution independent. winforms is not. WPF is not "blurry", if you have a WPF application that looks blurry just [change the font rendering mode](http://stackoverflow.com/a/18091149/643085). – Federico Berasategui Sep 22 '13 at 23:28
  • 1
    the difference between WPF and winforms is that WPF does not suck and is not completely useless as explained [here](http://stackoverflow.com/a/18931755/643085). And no, if you create a WPF application using the Visual Studio designer it is not going to be resolution independent as explained [here](http://stackoverflow.com/a/18927377/643085). You need to type XAML manually and use the appropiate containers depending on your needs. – Federico Berasategui Sep 22 '13 at 23:30
  • @HighCore : Thanks so much for your response! You want to say, one should hard code the height and width for our application as per 800*600, or whatever like wise writing a media query in css!?!? – user2804762 Sep 23 '13 at 02:26
  • @HighCore: You may also change the resolution of your screen (and re-size them) & then, you can see the how visual studio and other component of your screen looks. Hope it will you to understand what I am confuse about. thanks! – user2804762 Sep 23 '13 at 02:30
  • 1
    I don't see any problems in Visual Studio (nor in any other application) when changing screen resolution. And no, you must never hardcode the window (nor element sizes) in WPF. Things such as Buttons and the like sometimes need a fixed size, but then you may apply a LayoutTransform to the whole Window to compensate for fixed sizes in different resolutions. – Federico Berasategui Sep 23 '13 at 03:09
  • 1
    You can also put a `ViewBox` into your application which will scale the contents when screen resolutions change. That way, whether the screen resolution is 800 x 600 or 1920 x 1080, the application always looks the same. – Tony Vitabile Sep 26 '13 at 21:49
  • 1
    WPF is the Breaking Bad of Windows UI Frameworks - critically acclaimed , extolled by anyone who uses it to everyone else, but takes a bit of time to get into. Don't forget that one of the many reasons it is faster than WinForms is that it is all hardware accelerated using the DirectX pipeline! Combine that with the rich customisation of XAML, the modularity of MVVM, the simplicity of Data Bindings and you end up looking back with disgust at your old, Windows Forms using self. – Will Faithfull Oct 08 '13 at 23:24

2 Answers2

14

To answer this question properly I should write a whole chapter, but I keep it short:

There are three major differences between a WPF application and a Windows Forms application: Layout, Render, Presentation


Layout:

WPF layout system provides a greater flexibility in arranging the elements on the fly. It is based on the Element Bounding Box (as opposed to precise pixels in WinForms) and Measure and Arrange mechanics (as opposed to UpdateLayout in WinForms) that automatically and dynamically finds the place for each element without any need for a manual update.

Basically, all elements bounding box are measured first and then are arranged using multiple methods such as Measure, MeasureCore, ArrangeCore, MeasureOverride, etc.

Unlike WinForms, where you have a pixel-perfect size for everything, in WPF you have much more options and complexity such as Width, ActualWidth and DesiredSize (and even Transforms as LayoutTransform) for the same element.

This is why

  • As you type in a WPF TextBox, its width might increase and push other elements away or even push some elements into a new row (like the menu bar you've observed)

  • As the size of a control changes, it affects the available space for other elements. So their size and location might change accordingly.

  • When the window is being re-sized or resolution is changed, it immediately updates the layout and changes the size of elements in order to fill or fit the space. Here you'll find out more about Layouts.

  • using Margin alone (without using layout capabilities) to arrange elements is not the best idea in WPF. As it's the WinForms mindset which isn't much helpful while developing WPF.


Render:

WPF uses double data type for Layout (as opposed to pixel-perfect WinForms) and therefore you might see the edges blurry sometimes, but it can be avoided with SnapToDevicePixels=true.

WPF is much more efficient in utilizing the GPU to render a GUI. Try a grid of 30x30 TextBoxes in a Windows Forms application and a WPF application. No matter how messy you write the WPF, it never blinks and it still runs much faster than Windows Forms. Even adding a handful of animations, visual effects and styles on them does not hurt your performance like in Windows Forms.

Remark: To avoid a speed decrease and blinking in a Windows Forms application, you should set DoubleBuffer of the form to "true".

You can use any Transform as RenderTransform to easily implement smooth zoom/rotate, or develop custom GPU-based shader effects, and much more in WPF. (I think everyone agrees that doing such things in WinForms is feasible but real pain and you most likely will give up and move to GDI+ or DX if not out of frustration then because of the bad performance.)


And the last and the most important:

Focus on presentation:

When develping WPF Applications you have to stop thinking in Windows Forms: No more UI events, accessing controls by their names and writing logic in code-behind and start to think in WPF: Binding, Commands, Resources, Styles, Templates, Converters, DependencyProperties and their callbacks.

  • The real power of WPF lies in separation of 'View' and 'Logic', Which can be achieved using the MVVM pattern.

  • It makes the most visually-complicated problems quite simple and easy to develop and easy to write Unit Tests for.

  • Once you got the hang of it, you will realize there's no limit in how you can present the data or show off an awesome GUI looks.

If you've planned to switch to WPF, you've made the right decision. Always stick to MVVM and AVOID CODE-BEHIND AT ALL COSTS! (i.e. unless you are doing a pure UI operation: do not write code in .xaml.cs files, do not access x:Name in cs files and avoid UI events.)

Bizhan
  • 16,157
  • 9
  • 63
  • 101
7

Windows Forms (WinForms) and Windows Presentation Foundation (WPF) are two different ways of building the user interface for your application. Windows Forms is the older technology and its controls are found in the System.Windows.Forms namespace. WPF is a newer technology and its controls are found in the System.Windows.Controls namespace.

WPF

Pros:

  • Powerful styling and skinning structure
  • Easy to create your own look and feel
  • Does support Windows Forms
  • The future technology for developing Windows Vista applications
  • The ability to reuse existing code
  • Highly advanced data binding possible

Cons:

  • Declarative vs. procedural code
  • Requires .NET Framework 3.0
  • Compared to Windows Forms, still in development phase
  • Requires Dx9 compatible video card for advanced graphics

Windows Forms

Pros:

  • Extensive documentation to be found on the Internet
  • Plenty of examples
  • Does support WPF

Cons:

  • How long will this be supported? (I've read somewhere that Microsoft is just developing WPF now, only maintenance for Windows Forms).
  • Design your own look and feel in an application is a lot of work.
Community
  • 1
  • 1
Madhavan
  • 232
  • 1
  • 7
  • 15