March, 2010

  • The Old New Thing

    What happens if I drag the mouse by exactly the amount specified by SM_CXDRAG?

    • 17 Comments

    The drag sensitivity is specified by the system metrics SM_CXDRAG and SM_CYDRAG. What happens if I drag the mouse by exactly the amount specified by these two parameters?

    Nothing.

    These parameters control the drag insensitivity of the mouse. If your mouse motion is less than or equal to this amount, then nothing happens. This is spelled out in the documentation for GetSystemMetrics:

    The number of pixels on either side of a mouse-down point that the mouse pointer can move before a drag operation begins.

    It's how far the mouse can move before the system detects a drag. In code, the algorithm is as follows:

    BOOL ShouldStartDragging(POINT ptStart, POINT ptCur)
    {
        RECT rc = { ptStart.x, ptStart.y, ptStart.x, ptStart.y };
        InflateRect(&rc, GetSystemMetrics(SM_CXDRAG),
                             GetSystemMetrics(SM_CYDRAG));
        return !PtInRect(&rc, ptCur);
    }
    

    Some people appear to have read a bit too much into the fluffy description of this setting. I wrote the text to be vague so I wouldn't have to go into annoyingly precise details. It specifies how far the mouse must move, but I didn't say exactly how. Otherwise, the text (which is pretty full already) would have had to say something unwieldy like "Drag sensitivity specifies the distance (in pixels) beyond which the mouse must move with the button held down..." I did say that "the icon will begin dragging when you have moved the mouse the necessary distance." This was my way of saying, "The test icon shows you what happens. Just fiddle with the setting until the test icon behaves the way you like."

    In retrospect, I could've simply changed the word must to can.

  • The Old New Thing

    Voicemail security, even stronger than bank security

    • 44 Comments

    Microsoft's telephone department takes security very seriously. Your voicemail password must be at least eight digits long.

    By comparison, the password for my ATM card is only four digits long.

    Because voicemail is that important, I guess.

    (Yes, I know about two-factor authentication. I'm writing this only half-jokingly.)

  • The Old New Thing

    Microspeak: Dialogue

    • 24 Comments

    Why have a conversation when you can dialogue?

    I think this is minimal work, but do others care? If they don't, then this is one for the ideas that failed bin. If they do, well let's dialogue...

    No need to talk when you can dialogue.

  • The Old New Thing

    Chilly Hilly 2010 kicked my butt

    • 8 Comments

    This year, I was woefully unprepared for the annual Chilly Hilly ride, not having gotten on my bicycle for the entire month of February. And I paid dearly for this lack of preparation, conking out and ending up walking up some of the last few hills.

    I rode with a few other people, but I quickly ended up lagging behind them. They would sometimes stop to let me catch up, but I told them not to bother and just go at their own pace. At one point, I ran over a nail and lost precious time to a flat tire. (I took the flat tire as an opportunity to take my midpoint break, since it occurred just a half mile or so from the cider stop.) After patching the flat, I caught up to the rest of the group at the cider stop, where they were nearly ready to resume the ride. We left the cider stop together, but I quickly fell behind.

    I rolled into the finish as the rest of the group finished up their chili (a traditional post-ride snack), so we all headed out directly to the ferry. (Basically, I used their break time as my opportunity to catch up.) We were just in time for the 1:10 run, but we were too far back in line and they stopped accepting riders just as we reached the front. I guess I had time to have some chili after all, but by this point I didn't want to lose my place in line.

    My record against Chilly Hilly is now even at 2 wins, 2 losses.

    Ferry trivia: Even though there was room for more bicycles on the ferry, they wouldn't accept any more. This wasn't because they were being mean. They were following safety rules: While the limiting factor in how many cars they will allow on the ferry is the amount of space on the ferry deck, the limiting factor in how many bicycles they will accept on the ferry is the number of life jackets they have.

    Nobody would know: Right near the start, a wine store advertised that it was offering wine tastings. Don't just lubricate your bicycle; lubricate yourself! One of my friends who was riding by himself noted "I saw that sign and thought to myself, you know, I could just go in there, drink wine for three hours, then tootle back to the ferry for the return trip, and nobody would know." I wonder if anybody actually did that.

    Chilly Hilly trivia: There were 6028 riders this year, a huge increase from the 3585 riders last year.

    Are you sick of all these little blurbs yet? Photos of the ferry ride from the Seattle P-I. The Kitsap Sun link above also has pictures of the ride itself.

  • The Old New Thing

    When does STARTF_USESHOWWINDOW override the parameter passed to ShowWindow()?

    • 6 Comments

    kokorozashi wants to know what the rules are which govern when the second parameter to ShowWindow is overridden by the STARTF_USESHOWWINDOW flag.

    The guiding principle is that the parameter is ignored if the window manager thinks that the window you're creating is the application's main window.

    The details behind the implementation of this principle change over time, so everything from here down is implementation detail and should not be relied upon. I'm providing it merely to satisfy your curiosity.

    To reiterate, do not rely on information in the second half of this article because it can and will change.

    In fact, just to emphasize the point, I'm going to give the rules as they once were, not as they are today. So anybody who relies on this information is relying on implementation details of Windows which are no longer true.

    The window manager heuristics for determining whether the second parameter to ShowWindow should be overridden were once as follows:

    Rule zero: If the override has already been used, then don't use it again.

    Rule one: The easy case. If the second parameter was SW_SHOWDEFAULT, then the application was explicitly permitting the second parameter to ShowWindow to be overridden by the STARTF_USESHOWWINDOW flag, so let it happen.

    Rule two: Check the following properties.

    1. The STARTF_USESHOWWINDOW flag was set.
    2. The window was top-level.
    3. The window was not owned.
    4. The window had the WS_CAPTION style.
    5. The window was not system-modal.
    6. The second parameter to ShowWindow was SW_SHOWNORMAL or SW_SHOW.

    Let's look at these heuristics one at a time.

    First, the STARTF_USESHOWWINDOW flag needed to be set: If it wasn't, then there wasn't anything to override with.

    Next, the window needed to be top-level (not a child window). Because a child window clearly is not the application's main window.

    The window also must not have been owned. An owned window is not the main window (the owner would be a much better candidate), and besides, it would be bad to have minimized or hidden an owned window, since that would have left the owner sitting around for apparently no reason. Even worse if the window being created was intended to be modal to the owner: You would have had a disabled window on the screen, and the window you needed to close in order to get that window enabled again was hidden!

    Another rule was that the window had to have a caption. This made it less likely that splash screens and other incidental windows would be misdetected as the application's main window.

    System-modal windows were also excluded, because you didn't want system-critical error messages to be mistaken for the application's main window. (Especially if the action was SW_HIDE!)

    The second parameter to ShowWindow had to be one of the special values SW_SHOW or SW_SHOWNORMAL. These values were most likely to be passed by applications which were not particular about how the window was shown. They would be comparatively unlikely to be upset that their attempt to show the window was overridden.

    Once a window was identified as a likely main window (either by explicitly saying so via SW_SHOWDEFAULT or implicitly via the heuristics), the second parameter to ShowWindow was ignored and replaced with the value specified by STARTF_USESHOWWINDOW.

    There was some other fiddling that happened, but they aren't really important to the topic at hand, so I'll ignore them.

    Again, I reiterate that this information is provided merely to satisfy your curiosity and must not be relied upon by applications, since the heuristics may be tweaked in future versions of Windows. If you want the STARTF_USESHOWWINDOW flag to have an effect on your program, just pass SW_SHOWDEFAULT to ShowWindow. That's the value that says, "No really, I'm asking for it. Lemme have it."

Page 4 of 4 (35 items) 1234