>>Ok - so in a way it's pretty similar - my gizmo handles this as well. For the lookups - a trick is to use a modal form for editing the lookup list - then when you close that form - the underlying form that called is requries the lookup view. Sharing data-sessions and perhaps even using the same view and same datasession are little tricks you can do to make this happen.
>>I really went off the deep-end on one application I did to deal with this. I used the StoneField Database Toolkit to store a bunch of meta-data - then I created a class for all my lookup fields - if you right-clicked on it - then a form was dynamically created to do data-entry on the lookup table based on what was in the SDT meta-data tables (so you could dynamically create a textboxs or a checkboxs, datefield, etc). That was a really nice piece of work, because it saved me from having to create what would of been close to 100 lookup screens. You combine that with the auto-requerying gizmo on a timer, and then the check-for-update-confilicts dynamic screens when saving - then you really got something pretty special. In my case doing all this was a big deal for the customer because they had too many situations where there was more than one user looking at the same dataset at the same time. Having the data auto-refresh on their screen every xx seconds saved them a bunch of problems they were having because of this. Years and years ago I showed the way I was using SDT and meta-data to generate my lookup-editor screens on the fly to Doug Henning and he was pretty impressed.
>
>I didn't have to do this in VFP, mostly because there were very few conflicts - about 90% was around medicine where you don't really have anything (item, supplier, customer, location) that takes a significant amount of traffic, it's spread very evenly, so cases of cross-editing or one needing to have latest edits from another were quite rare. Most of the time I didn't even have to devise a petard, far from your artillery.
>
>However the lookup forms, back in FPD days, are a different matter. Even back then, when life was so much simpler, I had the need to have perhaps 30-40 of these, so I was seriously looking for an automated way to display, sort, select. The first 2-3 versions were browse on heavy steroids, then browse with OKL on every key (incremental search was the keyword) then gave it all up and rebuilt from scratch. In the end, I had a driver prg which would call a few generated snippets - and these were generated on the fly, on first call. I'd only have to write one line of code, "do view with {field list here}" (plus a few more parameters, like which is the key field to return) and then it would not only generate the little prg with the snippets, it would replace the call with "do view with {snippet_prg_name}, ..." and comment the original call out (yeh you could do that in FPD, it would keep the fxp open but would close the prg - no more so). In that code I was copying the visible records into an array and display the elements of that array using simple @say commands, moving the elements of the array up or down depending on navigation... and it was blazingly fast :).
>
>Walter, this is what I meant with retirement. See how fast I slip into hunters' stories?

Yeah, I can add a few more.. but I guess you already know most of them :)