>Steve -
>
>>With this, there is no form. Just old fpw26 code and a GET stack.
>
>you are wrong - vfp9 running fpw26 code creates a (somewhat different) form behind the scene.
>If you have a sufficiently large app to maintain, you can work even through OO interfaces -
>which is better IMHO when not only accessing form, but subcontrol props.

That's why I said to issue all those gets inside a form.

1. run a blank form, of sufficient size to show 25 rows and 80 columns in its own fontsize - assume 15 pixels or thereabouts per character position, or use fontmetric() calls to calculate right
2. Run all the fpd26 say-get-read code from form.activate
3. have a breakpoint somewhere and observe the form in the debugger. See the pageframe, page1 in it, all the controls created for the gets. Then code some stuff in valids and whens to interact with the form - this time thisform can be used, references to other controls too. The names of all controls should be the same each time - they are created dynamically, but they should be created the same way each time. Also, there may be some code to traverse the controls and store references to them into an array or collection (member of the form), and then any manipulation may get the reference to any control from that array or collection (addressed by the controlsource - because the controlsource was the parameter in old GetObj()).

This way the legacy FPD/FPW code can be hosted inside a VFP form under our control (not inside _Screen, as VFP would do on its own), and then that control can be exercised. The host form may breathe new life into the old code, with just minimal adjustments to that code.