>To me it is easier than to link parent and child grids, use SET RELATION, etc. I don't see a problem with adding, editing and deleting records in a view or cursor which is a grid recordsource. You manipulate the cursor records and just refresh the grid.
>
>Hi Nick,
>I tried to map out what you said and maybe this is the stumbling block:
>I have built several systems using using the txtbtns class as basis for my navigation buttons. With that approach you click on Edit (or Add) buttons to make changes to data on a form, and then click on Save or Revert to save changes or ignore changes. I'll bet you make changes and they're automatically saved. If this is true, then it looks like that design decision that I made a year ago has come back to bite me.
>Bill

Hi Bill,

I see you are using the wizards code. I never used wizards - only commercial frameworks or my own code. My typical one-to many forms (like Invoices - Invoice Items) has 2 grids - for parent and child records. Parent source is a view with record buffering, child source - parameterized view with table buffering. You can navigate through the parent records by scrolling the grid, or using navigational buttons in a toolbar. In addition to parent grid there is also the container with all parent view fields (if they all do not fit into the grid). Depending on number of fields, the child part of the form may also have the container with Details view. Usually the child part includes calculating the totals for invoice items on the fly.
Depending on customer requests I may allow editing data in grid or in details container, or in both. There is no automatic data saving - you have to click on Save button. If you made the changes and try to move the record pointer, you get the messagebox Save?/Yes/No/Cancel. But the framework takes care of that. I sent you the sample screenshots by e-mail.