Although hard-coding the video resolution may work for now, you may run into a problem later on if you've got users who might configure "large font" configuration. 1024x768 with large font is roughly the same as 800x600 with small font. 800x600 with large font is effectively the same as 640x480 in small font.
Basically, the approach I used was to add a "set video resolution" menu item. This item presents a list of video resolutions (determined through API calls), and allows user to make selection. I then switch to the resolution, and present a confirmation dialog (with the default as "No"). If the user confirms, then it stores this info in a config file somewhere (that is read upon program startup). If the selection is rejected, or the timeout occurs, then the screen reverts to the previous video configuration.
The config file that gets stored is used on program start to determine the desired video resolution so that it can automatically select the video resolution (i.e. it "remembers" what was last selected).
Upon program exit the video is returned to the original configuration as seen at program startup. The only tricky thing you might need to worry about is handing the situation where you might have two instances of the program running on the same computer. If you have that possiblity you need to make sure that only the first instance will switch resolution, and the last instance to exit will restore the original video resolution.


As an aside... one thing that I've discovered -- dealing with different video resolutions and various DPI settings (what is changed by selecting "large font" or "small font"). It's *much* easier to deal with in VFP than in FPW2.6. Where the problem becomes apparent is whenever you've got an interface where windows get "stacked" or placed adjacent one another (either horizontally or vertically). Whenever the DPI settings don't match between the computer that compiled the program and the one running the program don't match, you get a situation where the windows end up overlapping or have gaps between them. The messy bit is remembering which font was used as the basis of the foxel-to-pixel conversion. The row-column positions are based on the parent -- so the upper left corner of the window is determined by the parent window font. The height and width are based on the object itself. If the same font is used throughout the program then it's not a problem -- but if you switch fonts, you have to worry about this. Even after getting all of these conversions right, due to rounding, you may still end up with 1-pixel overlaps or 1-pixel gaps...