>>>Just occurred to me that back in FPD days we were doing something I've never seen demoed in any tool... because it's a tad complicated. And "why would anyone need that" is the question with a ready answer.
>>>
>>>Here's the scenario. Form for data entry of a document (or anything else, for that matter), and at some point you need to create a FK into a lookup table. The lookup table is either too long or too wide for a combo, so there's a search form which opens up (this is where practically every demo loses me, they never have anything but combo at this point). In that search form you find your lookup record, except you notice a glaring error (ommision or commision, irrelevant) or you simply don't find it. You open up the lookup editing form (or if you're Mike Yearwood, it's the same form - right, Mike? - so you do it on the spot in the search form). Save the changed record in the lookup, return the PK of the found or edited or added record to the caller form... and, sheesh, you now need to refresh the cursor, assuming it wasn't the same cursor as in the lookup search and/or edit form. So you refresh that and we live happily ever after.
>>
>>I usually use the invoices, customers as the scenario for this. Believe it or not, a recent contract involved exactly my design, but they did not get it. The savings and stability would have been significant.
>>
>>The invoice form starts an add in an invoice details cursor. The user cannot find the customer by customer code. So the customer data-entry/picklist form appears. The cursor for the list page is the same cursor for the customer lookup in the invoice form. The customer form adopted the data session of the invoice form. Each cursor is distinctly named and always serves a singular purpose. A list of customers is always a list of customers. The user adds the customer in a customer detail cursor. The newly added customer record is inserted into the list cursor and tableupdate is suppressed in the list.
>
>So the customer table gets its tableupdate when the invoice is saved then right? Not when you've created the new customer from the customer screen? My concern would be what if two users are creating the same new customer at the same time? -- then you have a problem. The advantage is that you don't have to requerry the customer view after you've closed the customer form and gone back to the invoice screen so it's easier to write - but it seems like you're kinda taking a chance by doing it this way......assuming I understand all this correctly.

Yup, that's the only hazardous point I see there... I was acquainted with Mike's way of doing forms at some point, and if I'd ever want to do a framework from scratch I'd probably go that way too (and ask Mike whether I could steal some). Considering how long ago that was, it must be rock solid for a number of years now - too bad he couldn't apply it in this case.