>I've read what everyone has said about the changing video resolutions and agree with it for the most part. However, I can understand why you would want to automate that process at the users request. Many games run in a higher resolution setting than Windows is set to. It would be very annoying for the user to get a message telling them to go and change the resolution themeselves everytime the game is run. You would be considered a joke in the industry for recomending a design like that. Good interface and application design means you take care of the tasks for the user, not tell them to go and do it themselves.
>
>This is a case I think where a programmer needs to understand the purpose of the application. For an application that always requires the user to be in the 1024x768 mode then you should probably try to automate switching the resolution for them. Telling them to go change it themselves in Windows is kind of a cop out if the user runs the application many times a day. I know most of my users would be much happier with it switching for them automatically. They are working folk who just want to get their jobs done; not control freaks who are going to flip out when the resolution changes.
>
>For comercial apps you probably would need to give them an option - Swith to 1024x768 or quit. When they click 1024x768 then the resolution changes and the app launches. I don't think telling them to go change it themselves is ever a good idea. Too much support overhead and simply bad application design. Of course when the app quits you should ask them if they wish to set it back or do it for them automatically. Remember the game designers here. If the app requires the resolution you just simply don't have a choice.
>
It's easy enough to do - the actual work is done by a single API call, ChangeDisplaySettings(), but it has lots of potential consequences. THe following is cut from the MSDN library API description
ChangeDisplaySettings
The ChangeDisplaySettings function changes the settings of the default display device to the graphics mode specified in lpDevMode.
To change the settings of a specified display device, use the ChangeDisplaySettingsEx function.
LONG ChangeDisplaySettings(
LPDEVMODE lpDevMode, // graphics mode
DWORD dwflags // graphics mode options
);
You'd declare it as:
DECLARE INTEGER ChangeDisplaySettings IN USER32 STRING @ lpDevMode, INTEGER dwFlags
If you built the required DevMode structure using CLSHEAP to allocate a static block to hold the DEVMODE structure, you'd use:
DECLARE INTEGER ChangeDisplaySettings IN USER32 INTEGER lpDevMode INTEGER dwFlags
A DEVMODE structure is moderately complex in that there are a lot of things in it; I'd recommend careful reading of the MSDN library before diving in. I'd probably try to write the actual API manipulations in another language (VC++ would be a good choice, especially with useful sample code in the MSDN) and exposing the operation to VFP through a C-style DLL call or COM interface. The structure would be constructable using a VFP string to hold the structure (there are no embedded structure pointers from a quick read), or you could allocate a static memory block using CLSHEAP, and very likely it's implemented, or easily implementable, with Christof Lange's STRUCT class. Only a small number of the structure members are used for displays from reading the description of the API call in "Windows NT WIN32 API SuperBible" by Richard Simon. There's no discussion of it in Dan Appleman's first book, but he's written two more since, so there might be sample VB code somewhere.
You'll need to develop a mechanism to block the user from resetting the display from outside your app, and I'd want to do something to allow the user to preserve the state of his Desktop and other apps on entry.
You'll also need to broadcast a Windows message to all the other Windows things using PostMessage() whenever you use the API call to let them know that things have been changed. It's a single WM_DISPLAYCHANGE message after a successful change of mode. You will be warned if a reboot is pending as a result of a change. NT and Win2K may not allow the change to be recorded. Add-on APIs like DirectX or things like MediaPlayer might have words with you. And there's always the issue of color depth and acceleration settings.
FWIW, disemboweling yourself with a rusty spoon may be a better-accepted and more enjoyable task. People using Active Desktop things, wallpaper, streamers, Active Accessibility features, older machines with less capable video cards, newer machines with multiple displays, viewport monitor interfaces and other things affected by display mode will probably be hunting you down. You also face the task of deciding the color depth, font mode settings and other issues.
The MSDN library includes C source for creating a Systray control that has all the necessary functionality in the index topic
display changing (GDI dynamically); the following is the text of the accompanying README file:
Dynamically Changing the Display Settings
The SetDisp sample creates a taskbar notification icon that you can use to
dynamically change your display settings. You can change resolution, color
depth, and refresh rate.
The core functions used are:
EnumDisplaySettings -- to get the display settings that are supported by
the video driver
ChangeDisplaySettings -- to test and set the display settings dynamically
and to update the registry with these settings
Shell_NotifyIcon -- to create and maintain the tray icon
TrackPopupMenu -- to implement the icon resolution context menu
Usage
------
To use the sample after building it with NMAKE, run SetDisp.EXE. This will
display a dialog box with a menu of possible resolutions and a will create a
tray icon. If you right mouse click on the tray icon the dialog will get
the focus. If you hide the dialog, you can bring it back up with this
technique. If you left mouse click the tray icon, you will get the list of
available settings. To remove the tray icon, you must close the main dialog.
When SetDisp starts up, it enumerates all of the device modes that the current
or default display driver supports. A #define controls filtering low frequency
refresh rates and limits the number of settings SetDisp reads in. After
enumerating the settings, they are added to the menu. On NT, we can easily
obtain the current setting with ENUM_CURRENT_SETTINGS, so we set the check
mark on the menu and bold the setting that was in use when SetDisp was
started.
When you select a new setting, SetDisp test to be sure the DEVMODE selected
has one of the display attributes set. All of the DEVMODEs used in SetDisp
should have these set since they came from the system. It then tests to see if
the system believes the DEVMODE is valid. If the change requires a system
reboot, a dialog notifies the user that this is not implemented. If the screen
change can be dynamic, a resolution changed is attempted. The user is prompted
to see if the new resolution is acceptable. This is important since the driver
may support a setting but the monitor is not able to display it correctly. To
ensure the user does not get stuck with a bad setting, a timer is used to
cancel the change if the user does not respond. The default time out is 10
seconds and is controlled by a #define. If the new setting is accepted, the
registry is updated. All of this is done using ChangeDisplaySettings.
Notes
-----
On Windows 95, you cannot use EnumDisplaySettings to get the current settings.
In this sample, this causes the check mark to not be displayed and the
current setting to not be made bold. Also on Windows 95, color depth changes
require a reboot.
Of the possible returns from ChangeDisplaySettings, only success and a reboot
required are currently handled. For success, a dynamic resolution change is
done. For a reboot required change, a message is displayed indicating that
the sample does not support a reboot.
If your driver has many resolutions, the menu may not fit on some resolutions.
This could be resolved with the use of sub menus for different settings
such as color depth or frequencies.
>For custom corporate apps if it is important enough to the client they can always purchase a bigger monitor. Almost always cheaper than redesigning an entire application. I've done this many times developing systems for people with 14" monitors. Just explain how much longer it takes to lay the screens out and get everything to fit. It's easy to justify the cost for most applications. 20 extra hours of interface layout & design * $100/hr = $2000. That is at least 5 new monitors for what it costs to lay the screen out to fit on a small monitor.Plus the users get the benefit of a better monitor for other applications. Many times only one or two users will use the space consuming screens. I've got several scheduling applications that would be ridiculous to try and fit on a smaller form. Give them the bigger monitors and lay those screens out to be 1024x768, make the others conform to 800x600.
>
>Unfortunately I've had poor luck using VFP's scrollable forms. They are ok if you don't add/remove objects on the fly, but for any sophisticated interfaces they just don't cut it. I've got a few of them in actual working situations but I avoid them now.
>
>I'd be interested in the code for switching the resolutions if anyone can figure it out. There are some systems I think that would be handy to have code for.
>
>One more word of advice: remember that you don't have to please anyone on this forum; you only have to please your clients. Ask your clients what they want and try to accomidate if possible.
>
>
>
>Greg Moss
>gmoss@midwest.net
>
>>I am using VFP6.0
>>I have an app developed in 1024x768. Some of the customers like to use 800x600. Is there a way that I can automatically check the resolution the user is curently running and then switch to 1024x768 when the app starts (if necessary) and then switch it back when the app closes?
>>
