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

The customer record could be committed and kept or not. It's a business decision if the customer is saved with the invoice or independently. If a second user is adding the customer at the same time - which is highly unlikely, the second customer gets a warning when the save is hit, retrieves the first customer.

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

The alternative is the far greater number of hoops the developers and the users are forced through not doing it this way. You can display a picklist of customers. Then you can leave the workflow to go to a separate customer screen and you have the same problem.