>Thanks to all for the responses. It appears that the correct answer is that the max [OBJECT].left can be is < 2*ScreenWidth. This is a bummer, because I can't bump the users' screen res (already at 1024x800) and now I don't know what to do. In this case, the user actually "places" the objects on the form in a design-mode and I'm loathe to tell them they can't make their form as wide as they want because it's a form representation of a physical environment.
>
>Any suggestions for a work-around? Is this "bug" being "fixed"?

In a similar case I was putting an ActiveX scrollbar on the screen, and did not use the VFP's scroll ability, because the form (class) was developed before VFP6. Instead, I used three layers of containers within containers. The outer container was big enough to fit on the form. The middle container was as big as needed, and by manipulating its .top property I achieved scrolling (setting to negative values most of the time). The inner containers were not really necessary, I used them just to accomodate a set of current controls while the form was built. It was a poll answer entry type of form, so depending on the questionnaire it would have more or less questions - but then all the controls were question-answer oriented, and I had the luxury of having a generic question class, which was based on a container with a few controls on it. I had some issues on automatic scrolling only, i.e. when the last visible container loses focus, I wanted the form to scroll to the next container.

This automatic scroll-on-focus-shift could actually be achieved without much coding, if you make sure the next control is visible; that would involve making sure both the current and the next control are visible (and probably the previous one as well), so you'd need some code to sufficiently center each control as it gains focus. In my case, I only had to center it vertically, because all the containers (outer, middle and inner) had the same width.