Fog Creek Software
Discussion Board

A form with lots of controls

I have a paper form that needs to be reproduced on screen.  This is for a client with low end PC's and they don't seem to want to upgrade the hardware.  About 300MHZ and lower with Win95 and some Win98.  Anyway the form will have about 400 label and edit controls on it.  In my tests when I place even 100 edit controls on a VB form it is "jerky" when it scrolls.  That is the whole window scrolls in the MDI app.  So I need a way to fix the jerkiness of the form.  I am using VB and might be able to use C++.  Any ideas would be appreciated.

Sunday, August 1, 2004

Why don't you use multiple forms in a 'wizard' style?

Sunday, August 1, 2004

That is what I suggested to the client but they want to see the "entire 'official' form" on the screen so I have to do my best to give 'em what they want.

Sunday, August 1, 2004

I think what they want is something they can use, and you have to educate them. However, do it exactly as they prescribed, and get them to sign their decisions. So when the head rolls and they come back asking for a different design (that wizard idea) you'll look like a winner.

Li-fan Chen
Sunday, August 1, 2004

Another thing you can do: do both (wizard and wizard less)... allow users to switch between the two using an undocumented F key. Then log who likes what best. Let's you build a case to help convince them to actually let the designing to the designer.

Li-fan Chen
Sunday, August 1, 2004

I don't know if it will make a difference but have you tried using the lightweight controls?

John Ridout
Sunday, August 1, 2004

I'm not arguing with you on the wizard thing but I am still looking for ways to get a form with a ton of controls to scroll smoothly.

Sunday, August 1, 2004

IIRC, you are limited to 255 controls on a VB 6 form.  A quick check online sees several references to this, so it's probably for real. 

Perhaps you can get around that with control arrays, but I wouldn't do it unless the arrays made sense in their own right.  Well, maybe you could array all your labels if they never change.

Anyway, your problem may be worse than you think.  I'd look at setting up some paging, or something like that.

Matt Conrad
Sunday, August 1, 2004

What do you mean by "lightweight controls" John?

Sunday, August 1, 2004

Embed a WebControl in your VB app and use an HTML form?

Sunday, August 1, 2004

That's interesting Ankur but I'm not familiar with getting data off of HTML forms on embedded webcontrol's.  Any ideas?

Sunday, August 1, 2004

>> Any ideas?

Dump this client because they are obviously too obtuse to benefit from the superior intellect that you espouse to embue upon them. Some people (most) just cannot be helped. The sooner you accept this hard learned fact, the sooner you can become at peace with the world--and yourself.

Anon-y-mous Cow-ard
Sunday, August 1, 2004

You're going to need to reduce the number of controls; there's no way around it.

The HTML control is an option, but with that number of inputs I wouldn't be surpised if the webbrowser control also starts to creak.

How far from a table is the form? Could you use a single grid control with the right set of styles & read-only settings? You could put a lot of fields on the screen in only one control that way.


Chris Tavares
Sunday, August 1, 2004

Just an idea to play around with ...

What about grouping your widgets in an ActiveX control?  This the form itself isn't rendering 100 controls ... just 4 or 5 ActiveX controls ... which in turn render ~ 20 widgets each.

Like I said, just an idea to possibly play around with ...

Sunday, August 1, 2004


I feel your pain. Instead of a wizard, have you tried just different tabs, with each section of the official form on one tab each, and then bring them a function that allows them you view the entire form that looks the way God intended.

Once they use it they will hopefully understand that the data entry form is a matter of workflow in the appliation, and the form viewer can then present the data in a way they are used to view it - regardless of them not entering the data in the actual form.

Make it easy to switch between the two, Edit/View forms so they can switch back and forth to their hearts content.

Good luck.

Sunday, August 1, 2004

Anon-y-mous Cow-ard,
Wow, what an insightful thought! I hope there are more software developers like you in the world. It will bring more business to me :)

Sunday, August 1, 2004

It's easy to get data to/from the HTML control. Just reference add a reference to the MS HTML Object Model and do it like this:

Dim oEl as HTMLInputTextElement
Dim sText as String

Set oEl = WebBrowserControl.document.getElementByID("txtBoxID")

sText = oEl.value

Personally, I think you'll have an easier time doing a form like this in HTML since there are many more layout options such as using Tables and Div tags to organize the page.

At least test it out by making a page with 100 controls on it (just do a bunch of text boxes) and open it right in IE on a machine with the target specs to see how it reacts.

Sunday, August 1, 2004

Sunday, August 1, 2004

Does it have to scroll continuously? You could do it wizard style using a vertical scrollbar to move from page to page and have keyboard focus at the ends of each page switch pages automagically.

Chris Altmann
Sunday, August 1, 2004

Here's a trick that sometimes works.

Implement it the way you suggested (as multiple tabs or pages). Tell the client it's just a prototype you put together to test out the various controls and that they'll get the "official" form as soon as you get everything working smoothly (make sure you have a Print option that prints the entire form the way they want to see it).

Let them play with it for a while to get used to it. If they still insist on having it all on one page at least you'll have bought some time. But usually once they see it they understand that tabs or multiple pages is fine. 

Tom H
Sunday, August 1, 2004

I designed applications for one client that fit this description. (think: government/bureaucratic forms.) The performance issue was even more severe with Windows 3.x which was the original platform for the app.

What I did was to develop a way to use one edit control that I repositioned on every chance of focus.

The problem then turned into one of making the window and the edit control emulate a more conventional "many-control" approach. This included:

- Maintaining an "edit buffer" data structure that contained the data under edit. When the edit is repositioned, the data in the edit needs to be written to the corresponding buffer location; and the data corresponding to the new edit location needs to be loaded into the edit control.

- Capturing all keystrokes that a user would reasonably expect to be able to change focus of the control.

- Triggering on mouse down events and mapping mouse clicks on edit locations to data entry locations.

It was non trivial but straightforward programming. I recommend using C++ to develop a window class that implements this behavior in a generic way.

Bored Bystander
Sunday, August 1, 2004

i don't know how the form looks but if it's very simple you may be able to recreate in excel, and add some macro, etc. or you can try access?

Sunday, August 1, 2004

If they really want an on-screen form that looks just like a paper form, have you considered using Acrobat Forms?

Sunday, August 1, 2004

I've used Excel for a form that had about 75 controls and it worked pretty well.  Here's what I did:

- Set the column width to 4 for all columns and merge cells as needed for input a label fields.
- Define names for all entry field ranges.
- Shade the cells for the label fields.
- Apply worksheet protection and unlock only the cells for entry fields.
- Hide the row and columns headers.
- Hide the grid lines.
- Set the move after enter direction to across.
- Hide the standard toolbars and create a custom toolbar.
- Code all database access, validation, and view customization in VBA.

The biggest drawback is the max length for cell contents. I think it's 255 characters.  I used the Excel form controls in several places to overcome this.

Going into it I thought it was going to turn out kludgy, but it actually didn't look half bad.  Moreover, the users liked it.

Yet another anon
Sunday, August 1, 2004

Just on the subject of hideous looking forms, has anyone ever been to a hotel/dentist/auto-electrician and noticed them still (to this day) using a hacked-together MS Access 2.0 application with garish green forms and zillions of UI controls on Windows 95 for running their core reservation/billing system?

Seriously, what monkeys can earn a living off writing that sort of stuff and peddling it to (gullible?!) customers?

Sunday, August 1, 2004

Probably the hotel/dentist/auto-electrician's kid.

Sunday, August 1, 2004

Tab control ?
Frames ?
Containers ?

I don't see this as difficult at all...
I have a client where we have a lot more than 100 controls.
Some are control arrays but  to serve a specific purpose, others are just plain old controls.

I make use of tabs, frames, and various functions to make it look like its all one screen.

Give it a shot!!!

Jonny Boy
Sunday, August 1, 2004

It's been my experience that even though the theoretical limit is 255 controls on one VB6 form, once you get above 100 you tend to have strange things happen (plus performance sucks, as you've found out).

So I think you need to switch technologies entirely.  Perhaps a web-based application, or a Word doc with many fields on it.  Or, what about an Adobe Acrobat Forms app?

Monday, August 2, 2004

One of the ideas that we're toying with for a similar situation is to create a two pane view.  The left pane is a set of tabs (or wizard) for data input, and the right pane is a read-only preview of what the paper form would look like.  This way the customer would still have the comfort of seeing the paper form as they go, but they would input the data in a reasonalbe manner.

Monday, August 2, 2004

I did something like this a while back in VB6.  Granted, it was dynamically created controls using control arrays, but if I remember right, I ran into your scrolling jerkiness problem.

I think I was showing/hiding the controls manually, but then when I placed them all in a container (picturebox?) and let it scroll that, the performance improved drastically.  Just a thought.

Monday, August 2, 2004

You don’t mention what tools you have at your disposal.

Since computers can’t be upgrade, then likely you have limited budgets here.

Ms-access sounds pretty good in this regards. First, you don’t have a limit of 255 controls on a form. In fact, it is in the 700+ range. Further, if you use a tab control, and sub-forms, then the number of controls displayed is un-limited. (each sub-form can have 700 controls, and you have 100’s of these sub forms). Why other IDE’S don’t have the concept of a form within a form I don’t know, but that is just one of those great features of access that is simple yet genius at work. You can read about my thoughts on sub-forms here:

Also, note that ms-access also has a page control that lets you move/page down though a form that is longer then the screen. (but, I have not used it for years, as  prefer tab controls..and I think long forms suck).

However, the fixation with you MUST follow the paper form exactly on the computer form might not be such a good idea here.  I would certainly follow the “flow” of the form and how data must be entered. However, a good application likely will present the form in  BETTER format then paper.

You don’t want to just duplicate the paper form, you want something BETTER then paper!

Further, there is all kinds of issues. The idea that you bring up a form, and start entering data might be the wrong approach. Perhaps you have repeat customers? Perhaps a normalized database where you first search, and then edit the customer info BEFORE you fill out the form is a better approach. Not only does a design that lets you search and edit customers BEFORE  you enter data on that customer work better, it means users develop a good work habit as they HAVE to search for a customer first (this reduces duplicate customer names by a ton). If the customer is not found, you THEN give them the option to add a new customer. With a simple form, then customer data is duplicated over and over.

Further, with customer information on file, then filling out much of the form can be automated (even things like credit card info etc can be pre-filled). So, now, filling out the address and other detailed customer information WILL NOT occur when you fill out the form. It would be silly to force the users to do this again and again for previous customers (and, please ....don’t “copy” the customer info!...use a normalized design for those repeat customers).

So, at first glance, it seems a good idea to duplicate the paper form, but with further research, it likely is not. In fact, each section of the form likely can be automated (popup, searching for special “sets” of defaults and descriptions etc).

I would press very hard for changing the format and how the form is to be entered on the computer. Computers let you process information, and they are NOT simply forms that represent paper. Don’t fall for this trap (heck, just type in word if you don’t need an application!).. 

So, sure, make the computer form similar and have it follow the paper forms flow, but DO NOT think that they must be the same, nor should they be.

What you need to do here is design an application, and NOT just a paper form. Don’t waste the customers money by building just a form on a screen.

Albert D. Kallal    (Microsoft Access MVP)
Edmonton, Alberta Canada

Albert D. Kallal
Monday, August 2, 2004

I second the acrobat solution or something like formflow.  If the client wants it all like paper forms, DO IT.  No need to code an entire application when you can buy one for a few hundred bucks.

Monday, August 2, 2004

A few have mentioned some forms packages (many of which requite a per seat license). If you do not need to store/save the form data, then the suggestions to use a forms system is good here.

So, if you don’t need a data driven system, then you might consider a xml solution. InfoPath is a rad forms system that supports xml directly (a lot of governments and big companies are now adopting InfoPath). Hence, you could consider InfoPath since InfoPath does not require sql server, nor even SharePoint to run. However, you can certainly can drive InfoPath from sql server, xml, or even JET (ms-access). (or, even a web site via .net services).

It would be a terrible solution to ignore all the issues of information retrieval here.

Do you need to store the data AFTER you fill out a form? (if yes, then you need a database).

Only you can answer these kinds of questions, and thus figure out if you are just building a form, or in fact building some system to store and retrieve information.

Anyway, you got some good suggestions here…it is up to you to figure out if the data needs to be saved, and then which road is right for you...

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, August 2, 2004

*  Recent Topics

*  Fog Creek Home