Hello. I originally posted this in microsoft.public.vc.mfc but didn't
seem to attract a response from MS. I'd like to report a bug in MFC's
floating toolbar resize code. For this, you will need a dual monitor
setup and Windows XP Service Pack 1 (I don't know if the problem
occurrs in previous Windows OSs with multimonitor support but I
suspect it does).

To reproduce the problem, use the Visual Studio .NET 2003 MFC project
wizard to create a GUI app with the "standard floating toolbar" GUI
option turned on. Build the test program and run it. Tear off the
toolbar and drag it over an empty area on your PRIMARY display (the
display you have designated primary in your display settings). Try to
resize the toolbar (e.g., make the width smaller so it becomes
vertical). This should work fine. Then, drag the toolbar so that it
is entirely contained within the SECONDARY display. Try to resize it
- you will not be able to do so.

This problem is caused by the fact that MFC tries to get the size of
the entire display using GetDesktopWindow and GetWindowRect. The
bounds returned by GetWindowRect of the desktop window seem to be the
bounds of the primary display only - they do not include the other
monitors. This means that the toolbar dimensions get clipped as out
of bounds if the toolbar is floating on the secondary display and the
resize code breaks.

Searching through the MFC source, I see that the MFC developers have
used this trick in lots of places. These will all have to be changed
to use GetSystemMetrics( SM_XVIRTUALSCREEN ) falling back on
GetSystemMetrics( SM_CXSCREEN ) if this metric returns zero because it
is unavailable (MFC devs should probably put this code in some
AfxGetDesktopRect function or some such).

Assuming that my analysis is correct, it would be a good idea to
change the GetDesktopWindow documentation so that people are warned
that the bounds of the desktop window are only the bounds of the
primary display and direct people to GetSystemMetrics instead.