>>>>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.

A lot of how stable that approach would be would also have a lot to do with how many user's you have and then of course the business situations where the odds of it being a problem can occur. In my case we had 100's of users, and due to the way they did things (and at what times they did things) that I knew for sure sooner or later there would be a problem. I was using a version of the VMP framework and manged to get all my stuff sort of integrated with that - so once I had it working it was easy to implement it on future projects - which I did do a few times :)
One of the ways my auto-requery gizmo worked was by cycling though all the views in the data-enviornment of a form and requerriying each view with parameters stored in an array that was part of my classlib. One of the tricky things was making sure that the views were requried in the right order - which was something else I was able to use SDT for.