>Mike
>
>Also this form class acts as a picklist, a child form, allowing add on the fly, edit on the fly, delete on the fly and find on the fly.
>
>Sounds very cool. If you don't mind, any tips on this? =)
>
>Dennis

It's all handled by how the form is called. When called from the menu, it's a parent or single data entry form. When called from a textbox class, it becomes a picklist - same form presentation, delayed instantiation makes only the list page appear so it is fast.

Because it is an actual data entry form, the user can correct items in the list, add items, delete items. Find on the fly is interesting. In a normal picklist, some keystrokes are made and the closest matching records are shown in a combobox dropdown or a new form is displayed with the matches. That form has to be closed in order to change the keystrokes - if the user made a mistake. Since my form is already displayed and has the search feature, the user can change the keystrokes (search criteria) without going back to the previous form.

When called from buttons inside a grid in a data entry form, it becomes a child data entry form. Imagine an invoice and the line items is too complex for a grid so that it has a large data entry form. Not a good example, but just go with it. The line items grid in the invoice form has buttons to summon the line items data entry form. It goes to the line items data entry page. The line items form can be summoned from the menu, allowing users to access line items across multiple invoices, for batch data entry correction etc.

I basically have one form class for the majority of my app. The users only have to learn one UI to use most of the app.