Fog Creek Software
Discussion Board




Form Designers and large apps

I know this is a little off topic for this forum but...

Up until now I have been builiding my GUIs by hand.
I'm sick of doing this and didn't plan to for my next project
which is going to be written in C#. I was playing around with Visual Studio.NET and quickly realized that when you
add controls to a form it puts them all in the same class.
This is fine for small apps but for larger apps with lots
of controls this is quickly going to become unmanageable.

How have people who use form designers on large apps been handling this?

It can't be that your expected to keep your entire GUI in a single class. Can it??

Thanks

btag
Tuesday, August 13, 2002

At least for .NET and WinForms:

User controls are your friends. If you've got a set of controls you use together repeatedly - for example, a password request box - then put them in a separate user control.

I would also argue that you should never draw directly onto the body of a top-level form. Instead, put the body of the form into a user control. It's easy to do and gives you a lot of flexibility later (to put the control into one side of a splitter, for example).

Also, while the form designer doesn't explicitly support this, its absolutely possible to do inheritance of forms. Use the designer to build the control layout, and then create a second class that inherits from the designer's class. That way your display is strictly in the base class (where the designer works) and your logic is strictly in the derived class (where you work). The only thing you have to do is make sure to make your event handlers virtual so you can override them.

The form designer is, unfortunately, descended from VB's, where it was very much "cram it all into the form." Luckily .NET and winforms are flexible enough to break out of the VB straightjacket.

Chris Tavares
Tuesday, August 13, 2002

"Also, while the form designer doesn't explicitly support this, its absolutely possible to do inheritance of forms"

Oh yes it does! :-) Check out the "Add Inherited Form" template in the Add Item dialog

Dunc
Tuesday, August 13, 2002

Holy cow! I had no idea that was in there.

That's really cool. Thanks for the tip!

-Chris

Chris Tavares
Tuesday, August 13, 2002

Why would you want to let the form designer work in the base form while the coder work in the derived form? Shouldn't it be the other way around? The form designer working his way around the code and adding additional functionality as necessary?

Humbug
Wednesday, August 14, 2002

In Delphi (and probably also in C#), you should avoid the temptation of putting too much code in the form class. In other words, use the form designer to create all controls, and hook up the event handlers to objects (defined in other source files) to do the actual processing tasks. Event handlers shouldn't be more than 2-3 lines of code.

If you have a control that requires complex painting or mouse message handling that is not easily deferred to a separate object, write a custom control.

Frederik Slijkerman
Wednesday, August 14, 2002

> use the form designer to create all controls, and hook up
> the event handlers to objects (defined in other source
> files) to do the actual processing tasks. Event handlers
> shouldn't be more than 2-3 lines of code.

I couldn't agree more. A good way to test for this is to take your design and try to figure out what would be affected if you had to change your work environment in some well-defined way (you can't predict every possible variation), e.g., changing from to C++ Builder to Visual C++.

If all your changes are limited to the UI, then you've hit design nirvana.

Of course, in this particular examples there will be compiler quirks to consider, but these *should* not be design issues.

Paulo Caetano
Wednesday, August 14, 2002

You guys, act a bit fanatic about separating the code from the visual stuff.
May be for some of you this come from VC++ where this method was proclaimed.

Do not be afraid of large files.

First you have to write classes. I can not imagine that in 5000-10000 lines of code no one will write a single class. If you do write many classes then it will be easy just to move them outside the file.

Second. You have to learn the features of the IDE. Having learnt all the Delphi short keys and similar stuff and using them I didn't need much the separation. When you need to go to the OnClick event you do not scroll down to the code you just double click on a button. When you need to go to a function just Ctr+Click on it and it goes. When you need to switch between two or more different parts of the app on which you work you just use bookmarks. And when you need something more you just use the advanced features of Find.

VS.net has many similar things. But that is not the point.
In VS.net it is very easy to create subfolders for the project. Every form or class in a subfolder is put in a different namespace.

And of course the code generated by the IDE for the form's design sake is in a #region which I keep CLOSED so it doesen't matter if it is in a separate file, i.e. wether I need to click on the tab to swich to a different file or on the + to expand the code.

In VC++ the hand coding for the interface was so much that you really had to separate them, but now it is done automatically and you usually do not need to interfere with that code. In Delphi the data is stored in the resources and are not included in the source code.

I have done several large projects and I haven't seen any serious problems with the fact that I don't create the forms by myself.

Boris Yankov
Wednesday, August 14, 2002

I don't use Microsoft tools so I can't help with any specifics, but I would never consider writing the human interface to an application of any complexity by hand.

On Mac OS X, I lay out all the parts of an application's human interface using Interface Builder and wire them up -- in Interface Builder -- to controller objects.  The interface loading machinery takes care of setting outlets (instance variables) in the controller objects to refer to views in the newly-loaded interface, as well as telling the views which action messages to send to which controller objects.  All without generating code.

The Cocoa framework on Mac OS X strongly encourages you to use a Model-View-Controller architecture.  An MVC architecture also works well in many, many other frameworks.  I suggest learning it if you're going to be developing end-user applications of any complexity.

Chris Hanson
Wednesday, August 14, 2002

>>> "You guys, act a bit fanatic about separating the code from the visual stuff.
May be for some of you this come from VC++ where this method was proclaimed.

Do not be afraid of large files. " <<<

It has nothing to do with large files.

It has to do with being able to flexibly change the UI without having to rewrite everything. When you've only got the one class, it's really tempting to put all the logic into the event handling functions. Then, when the marketing guy says "Remove that button" suddenly you've got all this working code hard wired into that button that needs to get ripped out and rewritten.

It also lets you have two people work on the code - a UI expert and a programmer. When everything's in one file, you bump into each other big time.

When you separate the UI from the logic maintenance gets a *lot* easier. For what it's worth, this is the same kind of thing that ASP.NET or JSP codebehind pages do in the web space.

Also, and it's just paranoia on my part, if my code is in my own file, there's a much lower chance of a bug in the form designer destroying any of my real code. It's rare, but it has happened with other tools (not VS.NET yet, but I expect it will one of these days).

Chris Tavares
Wednesday, August 14, 2002

Boris, the point I was trying to make is that if you manage to separate you biz classes from whatever your current tool gives you to build the UI, you have a better chance to reuse those biz classes when/if you have to use another tool.

Paulo Caetano
Thursday, August 15, 2002

Guys, may be it depends a bit on the development tool used.

First, in Delphi it is IMPOSSIBLE to corrupt the code, as I said the data is written to the app's resource. And I am pretty sure that it will not happen in the VC.net, it never happened to me and I've never heard it happen.

How often you see a UI expert? I think that at least 80% of the serious programs do not use such. And even if they were using it that would mean that the design is PREDESIGNED.

Of course that big code will be written in a separate place. For example a Word XP Import can be implemented in separate file(s). And of course if you have a function longer that 40-50 lines then you are doing something wrong.

My event handlers were never large. Even if some of them are long a bit, they concern a very specific to the interface code. So if one has to delete the 'Delete' button it is likely that he wants to delete the code related to it. Of course if it meant 'Delete this person' but there are several other places from where it could be deleted it will be likely that a DeletePerson() method be used and I do not argue with this. But it is nothing wrong with this that the DeletePerson is just an event handler with several controls refering to it.

Do not get me wrong. I am not trying to convince you to write everything in a single file. But the separation and the good OO design comes not by just splitting some code parts but by smart design and implementation.

Boris Yankov
Thursday, August 15, 2002

*  Recent Topics

*  Fog Creek Home