Question

I never knew this, but apparently:

By default, the system reduces a
minimized window to the size of its
taskbar button and moves the minimized
window to the taskbar. A restored
window is a window that has been
returned to its previous size and
position, that is, the size it was
before it was minimized or maximized.

In an application, we want to save the position/size of various windows at exit. This leads to a problem for minimized windows. Our solution is to restore all windows before running the save-state logic, but that just seems hacky. Is there a better way?

Answer 1

How about using GetWindowPlacement?
That returns a WINDOWPLACEMENT structure that contains information about the window’s coordinates in the restored position.

Remember that (as Leo Davidson points out in the comments) that you must respect the difference between workspace and screen coordinates. As the WINDOWPLACEMENT documentation explains:

The coordinates used in a
WINDOWPLACEMENT structure should be
used only by the GetWindowPlacement
and SetWindowPlacement functions.
Passing workspace coordinates to
functions which expect screen
coordinates (such as SetWindowPos)
will result in the window appearing in
the wrong location. For example, if
the taskbar is at the top of the
screen, saving window coordinates
using GetWindowPlacement and restoring
them using SetWindowPos causes the
window to appear to “creep” up the
screen.

Or, the simpler solution that I’ve no doubt used before is just to check if the window is minimized before saving the state, and if it is, skip saving any state information.

As far as explaining why a window changes its size when it gets minimized, Raymond Chen’s blog entry (and the linked entry as well) on the subject is mandatory reading. They don’t really change to their taskbar button’s size, but rather to a pre-defined size of 160×31. He explains that you can see this by minimizing a MDI child window into its parent—that’s really its size.