>
>Actually, I guess I wasn't clear enough about how these screens were set-up. They are only built using @ SAY/GET inside of a PRG file. There is no screen file for them - the original developers wrote the code manually.

That's what I assumed. With this approach VFP creates forms having an object model ***very similar*** to the object model generated by the screen converter working of the FPW .scx/sct.

Point 1: you can walk this object model and use an OOP-approach there: get handles to individual controls and set specific properties like .visible, .width and so on. Works after the Read activate. Tested.

Point 2: I was speculating that you can create VFP-forms directly from the form instances created by the "read" of those directly coded @get's. Haven't done it yet, but surely doable: I'ld bet on it <g>.

>While this code ran OK under VFP 8, the screen format looked terrible. I was just looking for suggestions on environment settings, font settings, (or some other settings) that might make the display a little more reasonable looking (some forms had overlapping controls, etc.).

Nothing there that I know of - and a "general resizer" based on DOS-assumptions feels akward.

>I decided I wanted to clean up some of the code, repoint various function calls to a class, etc. I don't have a consistent set of changes to make to each and every screen, so it doesn't lend itself to a nice automated tool.

Cleaning will give you IMHO always the best options.

>>nice automated tool.
Most of them are ugly stepchildren only able to do their work ;-)

good luck

thomas