How do I limit the size of the preview window used by Aero Snap?

A customer reported that the translucent preview shows by Aero Snap showed the wrong dimensions for their application window. "As you can see in the screen shot, the preview is too wide. Our application window has a maximum width, but the preview is fully half the width of the screen. How can we disable the Aero Snap feature?"

Whoa there, giving up so easily? Sounds like you're throwing the baby out with the bathwater.

To control the size of the preview window used by Aero Snap, you respond to the same message you've already been responding to in order to tell Windows the valid range of sizes for your window: WM_GET­MIN­MAX­INFO.

Start with our scratch program and make the following changes:

void OnGetMinMaxInfo(HWND hwnd, LPMINMAXINFO pmmi)
  pmmi->ptMaxTrackSize.x = 400;

// add to WndProc

We specify in the On­Get­Min­Max­Info function that the maximum width for the window is 400 pixels. (In real life, of course, you wouldn't hard-code the width, but this is just a proof of concept program.) Since we don't touch ptMaxTrackSize.y, we impose no additional constraints on the window height beyond what comes with Windows by default.

Run this program, and use Aero Snap to shove it against the edges of the screen. Observe that the Aero Snap preview respects our maximum window width.

I never heard back from the customer, so I assume this simple solution worked for them. The fact that they had to ask this question tells me that they hadn't been handling the WM_GET­MIN­MAX­INFO message at all; instead, they were enforcing their window size procedurally after the window manager already decided on the wrong size. Either they didn't seem to mind that the maximize and restore animations showed the window animating to the wrong size, or they couldn't figure out how to fix that problem either.

Comments (7)
  1. Joshua says:

    Or they turned those animations off. Some people do.

  2. James Schend says:

    @Joshua: One would hope their QA department tested the application with default Windows settings.

  3. Joshua says:

    Actually having most QA machines with non-default and varying settings smokes out more bugs than otherwise.

  4. James Schend says:

    @Joshua: Yes, but they should have at least *one* machine with default settings, and run their QA there first.

    I don't know if you're trying to be clever or what, but excusing the bug with "well maybe they turned off a Windows feature which is really hard to find and 99.9% of people will never turn off!" isn't a very compelling argument to me. Sure, "some people do." How likely are you to run into a single one of those people during your entire career?

    It's a bug.

  5. Worf says:

    It also requires people to look out for such things. When you're testing, either minimize/maximize isn't tested explicitly, or no one bothers noticing the issue.

    And after testing the same program on the Nth PC, they probably click, see result, done. You're expecting a level of detail which may simply not exist. If it's a bespoke app, if it works that's good enough. If it's a specialty app, ditto.

    As the app gets used by less and less people and costs more and more, polish goes way down. Specialy apps often do things that would make you cringe

  6. Neil says:

    The first, and last, time I cared about WM_GETMINMAXINFO I discovered that it got sent before WM_CREATE which meant that the answer was "I have no idea"…

  7. Cheong says:

    Last week I just found a component we've been using for years won't work (hangs) on Remote Desktop.

    We surely have QA, but test cases are usually designed to cover the functionality we're required to work out (business logic, etc.), often just cover little on the UI section, and usually do not cover any item in "Windows behaviour" region.

Comments are closed.

Skip to main content