John,

In one app I currently have under development the UI the client wanted was heavily parent-child form oriented. It tracks projects for a stained glass company. The Parent form shows a single project. On it is a pageframe with tabs for Windows, Frames, Installation, Painted Work, Protective Covering, Purchase Orders, Job Notes and Scanned Items. These are all of the children of the parent. The page for each has a display only grid of a p-view of the child records so they can at a glance see all the project Windows with totals like window count and total sq. ft. At the bottom of the page is a "hyperlink" label (like a button) that they click to lauch the child form where they do the edit/add on a p-view of the child table. This UI allows them to have two or more child windows open say working on Windows and Frames at the same time. The app is designed for running in at least 1024x768 video.

All child forms but the Purchase Order form show only child records. The PO form is basically child-grandchild for project POs to POLineItems. That form displays a PO at the top with a grid for edit/add of line items.

The UI has worked out well, the client is/was a Mac person and an artist so he was pretty involved in the UI design. But p-views have really made this all come together very well. Each child table has two p-views. One for edit and another for view which links in look up values from the codes table.

>Thanks for the explanation. It makes sense now. So if you had a Customer list in a grid with one column that had a control to show all orders for that customer when you press that control you launch the child form to show the child records.