WinForms: Design vs Code

Question

I am a solo dev building a WinForm App, C# & .Net 3.5, in VS2008.

It is, essentially, a glorified data entry and retrieval application. My question is, Is it normal to spend %60 + of my time on "design"?

The UI, placing all the controls, naming the controls something intuitive, setting properties on the UI controls(Modifier, onFocused color, etc). It seems that for every 30 minutes I spend writing code I srend twice that messing around with the UI. What am I doing wrong?

I realize that is an impossible question to answer so I'll settle for some general pointers.

• Is there a way to have certain property settings be set by default for all UI Controls?
• Is there a faster way of editing the existing ones then clicking and editing?
• Is this really a product of my lack of planning? Is the solution to have planned and written all this down so that I got it right the first time?

It is really very frustrating as I love the coding aspect but I feel I spend more time making sure my Font is readable(I have a semi-elderly user base)!

---

EDIT to further elaborate based on feedback!

The app I am making is a winform port of a webform, ASP.Net app. Fully functional and in use. I am not allowed to change the Database layer at this point but because of the nature of WinForm vs WebForm the UI has under gone major changes. I am leaving the DAL & BLL for the end so I can first see how much of them I can reuse.

I know that this probably isn't normal but seemed to make the most sense in this scenario. Does that make my question more clear?

Thanks!

~Patrick

Answer 1

Don't feel too bad - it doesn't sound like you're doing rocket science in the background of this app, so you should be spending way more time making sure the UI is right.

One quick note if you are not doing this already - when you first create a form, set the font at the form level. Then anything you drop on it will inherit that font by default.

Those little touches go a long way for your user experience.

Answer 2

Is there a faster way of editing the existing ones then clicking and editing?

You can CTRL+Click multiple form controls that have a common property (e.g. Font, ForegroundColor, or something), and make the change to all of the controls at once. The various controls' properties are also defined towards the top of your form code (I believe the section is normally collapsed by default). These properties get automatically updated when you use the Form Designer to make changes, but you could modify them in the code instead, using a Find+Replace if you have a lot of similar changes to make.

Is this really a product of my lack of planning? Is the solution to have planned and written all this down so that I got it right the first time?

While planning is always good to do, I don't think I've ever done a complete project where I haven't forgotten to account for something in my plans. A lot of times, you just don't notice certain things that you need to add in until you are able to poke around the form.

Is there a way to have certain property settings be set by default for all UI Controls?

routeNpingme's solution for this is a good one. :)

Answer 3

Use inheritance to centralise your own customisations e.g.

Add a class called MyButton, say:

using System;
using System.Drawing;
using System.Windows.Forms;

namespace MyApp
{
  class MyButton : Button
  {
    public MyButton()
    {
      this.BackColor = Color.Pink;
      this.Font = new Font(SystemFonts.DialogFont.FontFamily, 12, FontStyle.Bold, GraphicsUnit.Point);
    }

    protected override Size DefaultSize
    {
      get
      {
        return new Size(150, 50);
      }
    }
  }
}

And it will appear as a control in the Toolbox that you can drag and drop onto the Form instead of the regular button.

Answer 4

You're probably doing it backwards. You shouldn't really care much about fonts, colors, placement and look-and-feel until after you're done making it work. That saves lots of time tweaking controls that you might ultimately throw away. Even if you have a good mock-up of the UI, still do it afterwards. Or when the code ain't flowing. Which btw might be another explanation...