Microsoft training courses | Wise Owl - home page

Phone (01457) 858877 or email

WHY YOU SHOULD DEVELOP SYSTEMS IN WPF, NOT WINFORMS

Part one of a eleven-part series of blogs

We think - cautiously - that WPF is a better platform for client tool development than Windows Forms. This blog gives 10 reasons why.

  1. 10 reasons why WPF is better than Windows Forms (this article)
  2. 1 - WPF Forms are Quicker to Create
  3. 2 - Flow Layout Trumps Absolute Positioning
  4. 3 - WPF Works for Websites
  5. 4 - Styles are Much Better in WPF
  6. 5 - WPF is (I think) the Way of the Future
  7. 6 - Better Data Binding
  8. 7 - Selecting Controls in the Document Outline Window
  9. 8 - Triggers
  10. 9 - StoryBoards and Animations
  11. 10 - Drawing!
Posted by Andy Brown on 25 September 2012 | no comments

10 reasons why WPF is better than Windows Forms

A while back I blogged tentatively on which of Windows Presentation Foundation (WPF) or Windows Forms (WinForms) would turn out to be the future. 

WinForms or WPF choice in Visual Studio

The two main types of application you can create in Visual Studio (unless you're developing a website, in which case ASP.NET is a better bet).

 

With a few more months of experience of WPF under my belt, I'm going to stick my neck out with this follow-up blog and give 10 reasons why I'd rather use WPF.

I've left the old blog up, however, because I'm still not convinced developers will be more productive with WPF.  They'll certainly produce more exciting and enjoyable software, but minimalists may still create systems more quickly in Windows Forms.

Before I begin, though, a quick summary of what each approach involves.

An Overview of Windows Forms

For WinForms you draw one or more forms on screen, usually using Visual Studio:

Form in Windows Forms

A form for entering a film into a database, with the OK button selected.

 

The instructions to create the form are created in the underlying language (VB or C#).  Here are the code lines generated for the above form (I was using VB, but the C# would be similar):

Private Sub InitializeComponent()

 

Me.Label1 = New System.Windows.Forms.Label()

Me.txtFilmName = New System.Windows.Forms.TextBox()

Me.btnOK = New System.Windows.Forms.Button()

Me.btnCancel = New System.Windows.Forms.Button()

Me.GroupBox1 = New System.Windows.Forms.GroupBox()

Me.GroupBox1.SuspendLayout()

Me.SuspendLayout()

'

'Label1

'

Me.Label1.AutoSize = True

Me.Label1.Location = New System.Drawing.Point(20, 23)

Me.Label1.Name = "Label1"

Me.Label1.Size = New System.Drawing.Size(81, 13)

Me.Label1.TabIndex = 0

Me.Label1.Text = "Type film name:"

'

'txtFilmName

'

Me.txtFilmName.Location = New System.Drawing.Point(107, 20)

Me.txtFilmName.Name = "txtFilmName"

Me.txtFilmName.Size = New System.Drawing.Size(100, 20)

Me.txtFilmName.TabIndex = 1

'

'btnOK

'

Me.btnOK.Location = New System.Drawing.Point(57, 88)

Me.btnOK.Name = "btnOK"

Me.btnOK.Size = New System.Drawing.Size(75, 23)

Me.btnOK.TabIndex = 2

Me.btnOK.Text = "OK"

Me.btnOK.UseVisualStyleBackColor = True

'

'btnCancel

'

Me.btnCancel.Location = New System.Drawing.Point(144, 88)

Me.btnCancel.Name = "btnCancel"

Me.btnCancel.Size = New System.Drawing.Size(75, 23)

Me.btnCancel.TabIndex = 3

Me.btnCancel.Text = "Cancel"

Me.btnCancel.UseVisualStyleBackColor = True

'

'GroupBox1

'

Me.GroupBox1.Controls.Add(Me.txtFilmName)

Me.GroupBox1.Controls.Add(Me.Label1)

Me.GroupBox1.Location = New System.Drawing.Point(22, 15)

Me.GroupBox1.Name = "GroupBox1"

Me.GroupBox1.Size = New System.Drawing.Size(230, 56)

Me.GroupBox1.TabIndex = 4

Me.GroupBox1.TabStop = False

'

'frmFilm

'

Me.AutoScaleDimensions = New System.Drawing.SizeF(6.0!, 13.0!)

Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font

Me.ClientSize = New System.Drawing.Size(276, 135)

Me.Controls.Add(Me.GroupBox1)

Me.Controls.Add(Me.btnCancel)

Me.Controls.Add(Me.btnOK)

Me.Name = "frmFilm"

Me.Text = "Films"

Me.GroupBox1.ResumeLayout(False)

Me.GroupBox1.PerformLayout()

Me.ResumeLayout(False)

 

End Sub

The OK button shown has got properties like its width, height, etc, which you can adjust through the traditional Properties window:

Properties window for OK button

A small subset of the properties of a button.

 

Windows Forms is similar to its ancestor, VB6, and will look familiar to anyone who has created forms in Access or VBA.

An Overview of WPF

For WPF you create windows in XAML.  You can draw these on screen:

WPF window design

You can design WPF forms on screen, but it doesn't always work well and isn't always easy to use.

 

It's usually much quicker and easier to create your forms by writing XAML, the underlying form layout language (a variant of XML):

XAML for form in WPF

The XAML for the window shown above.

Thus although WPF windows and WinForms forms look similar, what happens behind the scenes is completely different.

 

Following that brief introduction, let's start looking at 10 reasons why WPF is a better bet for developing systems.

WHY YOU SHOULD DEVELOP SYSTEMS IN WPF, NOT WINFORMS

Part one of a eleven-part series of blogs

We think - cautiously - that WPF is a better platform for client tool development than Windows Forms. This blog gives 10 reasons why.

  1. 10 reasons why WPF is better than Windows Forms (this article)
  2. 1 - WPF Forms are Quicker to Create
  3. 2 - Flow Layout Trumps Absolute Positioning
  4. 3 - WPF Works for Websites
  5. 4 - Styles are Much Better in WPF
  6. 5 - WPF is (I think) the Way of the Future
  7. 6 - Better Data Binding
  8. 7 - Selecting Controls in the Document Outline Window
  9. 8 - Triggers
  10. 9 - StoryBoards and Animations
  11. 10 - Drawing!

Comments on this blog

This blog currently has no comments.

All content copyright Wise Owl Business Solutions Ltd 2014. All rights reserved.