Continued from New Multiple-Monitor Win32 API functions

If you use these new API functions to make your applications multiple monitor-friendly, what will happen on systems running a version of Windows that does not have the multimonitor functions? (Neither Windows 95 nor Windows NT 4.0 includes the multiple-monitor APIs.) They will crash, unless you do something about it. The solution is a new header file, Multimon.h, which uses GetProcAddress to determine whether the relevant functions are actually in the system DLLs. If they are not, it supplies default implementations of these functions. This header file actually contains source code, and if the COMPILE_MULTIMON_STUBS flag is set, the code will be compiled. This means that you should define COMPILE_MULTIMON_STUBS in one--and only one--source file that includes Multimon.h. You can include Multimon.h in as many source files as you want, but make sure that COMPILE_MULTIMON_STUBS is defined in only one. The end result of this process is a single executable file that will run on all versions of Win32.

There are also a few new rules you should follow if you want your programs to behave correctly on a multiple-monitor system. Remember that negative desktop coordinates are now valid, so don't assume otherwise. For example, don't hide your application by moving its window to a negative position. You should also take care when centering dialogs on a monitor. If you don't check which monitor your application is on, you may be centering your dialog on the wrong monitor.

Another potential pitfall is the incorrect casting of window message parameters that are window coordinates. Since negative coordinates used to be invalid, it didn't matter if you accidentally cast an integer position value to a DWORD.

If you follow sound coding practices in general, you should find that your application will require very little work to become multiple monitor-friendly. When Windows 98 is finally released, multiple-monitor systems will probably become fairly common. If you want to make your programs as high in quality as possible, or if you target a market where multiple monitors will be prevalent, add some multiple-monitor situations to your test plans.

Microsoft has done quite a good job of incorporating multiple-monitor support into an OS that wasn't designed for it. But applications written before multiple-monitor support was available may behave unreliably, especially when displayed on a monitor other than the primary monitor. My own experience has shown that while such problems can be frustrating, they can be worked out. Once you have adapted to the multi-monitor quirks of your applications, it's hard to go back to the confines of a single monitor. If you have an old 14-inch monitor sitting around, you may find it worthwhile to buy a cheap PCI video card and set up a second display.

Next: Figure 1: The Display Properties Control Panel

Published as Power Programming in the 4/7/98 issue of PC Magazine.