• The Old New Thing

    Follow-up: That shopautodotca seocontest online contest


    So I didn't win the shopautodotca seocontest search engine optimization contest, so I decided to check on how the actual winners were faring. After all, one of the winners was supposed to become the company's SEO manager.

    The top prize winners in the Google category and in the MSN category have both complained that they haven't received their prizes yet and have threatened to file a fraud claim. (Dead link to forum.) The top prize winner in the Yahoo category hasn't said anything one way or the other.

    Meanwhile, the forum hosted by the contest organizers was emptied of all messages, rendering it a breeding ground for message board spam. (It was subsequently taken down late last year.)

    I suspect that's the last I'll hear of this contest; I don't anticipate any resolution to emerge.

  • The Old New Thing

    Everyday is Grammer Day


    March fourth is not just a pun on march forth, but it's also National Grammar Day, sponsored by the Society for the Promotion of Good Grammar.

  • The Old New Thing

    Even your folder icons can be used as a Rorschach test


    Jenny Lam (now at Jackson Fish Market) forwarded me this picture of a USB thumb drive. She also reminded me of another one of those Windows as Rorschach test incidents that surrounded the Windows Vista folder icons.

    It was reported during one of the betas that the 16×16 folder icon looked like someone flipping the bird. Sure, this interpretation required some creativity, and it perhaps reflects more on the person making the observation than on the folder icon itself, but the report still had to be taken seriously, because one thing you don't want is a newspaper headline saying that your product uses crudely offensive imagery. And yes, we went back and changed the icon to avoid the problem.

    Now, if you take that Folderix flash drive and tilt your head to the right about 60°, you can turn it into somebody giving you the finger with their right hand: The folder tab is the thumb, the folder body is the back of the hand, and the USB connector is the extended middle finger.

    Who knows, maybe that was intentional after all.

  • The Old New Thing

    Wall Street bonus season's trickle-down


    Marketplace covers the businesses who are indirect beneficiaries of the Wall Street bonus season. Ted Fisher, who sells custom-tailored clothing, sees 35 to 40% of his business come in during the three months of bonus season. I suspect business near Redmond are similarly affected by Microsoft review season, though perhaps not as much now as before.

  • The Old New Thing

    How do I get the title of a dialog from a dialog resource?


    A customer submitted the following question:

    We are developing automated tests for our application. Among other things, our application uses property sheets, which means that the name of the tab is stored as the title of the dialog template resource. Since we want our automated tests to run on all language versions of our application, we don't want to hard-code the tab names in our automated test. I have not been able to find any information on how to programmatically extract the dialog titles from the dialog resources. Any pointers would be appreciated.

    I replied with some pointers:

    The customer was grateful for the pointers, then asked:

    Then the only way to do this is to load the dialog resource and parse the data looking for the string I want? Is it even possible to do this in C#?

    Well it depends on what your definition of "the only way" is.

    At the end of the day, somebody has to load the dialog resource and parse it, because after all that is what you said you want to do: "I want to get the title of the dialog from the dialog resource." The alternative is, what, psychic powers?

    There is no dialog template parsing library that comes with Win32. If you don't want to do the parsing, then maybe you can find somebody else who will. And if you're lucky, that other person may even have provided a C# interface.

  • The Old New Thing

    How do I suppress the default animation that occurs when I hide or show a window?


    A customer wanted to know how they can disable the default fade-in/fade-out animation that occurs when a window is hidden or shown. "I don't want to use WS_EX_TOOL­WINDOW because that causes my window to disappear from the taskbar. I tried Dwm­Enable­Composition but that affects the entire desktop and is too jarring. We want to suppress the effect because our program replaces one window with another, and we want the operation to be invisible to the user."

    Whoa, heading straight for Dwm­Enable­Composition? That's using a global solution to a local problem.

    To disable the animations on a specific window, use something like this:

    HRESULT DisableDwmAnimations(HWND hwnd)
        BOOL fDisable = TRUE;
        return DwmSetWindowAttribute(hwnd,

    Re-enabling the animations is left as an exercise for the reader.

  • The Old New Thing

    When you use a term, it helps if you know what the term means


    Some years ago (in a project far, far away) I received a piece of email from a member of the release management team asking me if a particular issue met the escrow reset bug bar or not, as it applied to an upcoming pre-RTM release.

    I asked, "What is the current escrow reset bar?" I thought this was a fair question. After all, in order to state whether or not the issue met the escrow reset criteria, I needed to know what the escrow reset criteria were. I figured they'd reply with something like "The escrow reset criteria are on this internal Web page. Please evaluate the issue against those criteria and get back to us."

    Instead, the response I got back was, "I'm not sure, let me check."

    Some time later, I received the answer.

    There is no formal set of criteria. It's taken on a case-by-case basis after discussion with the team responsible for the issue.

    I thought it was interesting that, first, somebody asked me to evaluate an issue against criteria I was not provided with; second, the person asking the question didn't know the criteria either; and third, it turns out that there were no criteria at all!

    According to their definition, the way to determine whether the issue met the escrow reset bar was to meet with the release management team themselves and let them make the call. In other words, they asked me to make a decision that only they could make.

    They decided not to hold a meeting to discuss the issue. I guess that means it didn't meet the escrow reset bar.

  • The Old New Thing

    How does Explorer determine the delay between clicking on an item and initiating an edit?


    Ian Boyd wants to know why the specific value of 500ms was chosen as the edit delay in Windows Explorer.

    Because it's your double-click time.

    Since the double-click action (execute) is not an extension of the single-click action (edit), Explorer (and more generally, list view) waits for the double-click timeout before entering edit mode so it can tell whether that first click was really a single-click on its own or a single-click on the way to a double-click.

    If the timeout were shorter than the double-click time, then double-clicking an item would end up having the first click trigger edit mode and the second click selecting text inside the editor.

    (If the timeout were longer, then everything would still work, but you would just have to wait longer.)

    Ian says, "Through my testing it does not appear linked to configurable double-click timeout." My guess is that Ian changed the double-click timeout not by calling Set­Double­Click­Time but by whacking a registry value directly. The values in the registry are loaded and cached at logon; you can update them all you want at runtime, nobody will care.

  • The Old New Thing

    STRICT_TYPED_ITEMIDS is the shell namespace version of the STRICT macro used by USER and GDI


    Starting with the Windows Vista PlatformSDK, defining the symbol STRICT_TYPED_ITEM­IDS before including shell header files changes declarations that previously had simply used ITEM­ID­LIST now use one of various types which are more clear about what type of ID list is being used.

    Think of it as the STRICT macro for the shell.

    The more precise names emphasize the form of the ID list:

    • ITEM­ID_CHILD represents an item ID relative to some implied shell folder. The item ID is followed by a null terminator and is therefore exactly one SH­ITEM­ID long. In file-system speak, this is a "file name."
    • ID­LIST_RELATIVE represents an item ID list relative to some implied shell folder. It can consist of any number of SH­ITEM­ID structures concatenated together, followed by a null terminator. This item ID list must be used in conjunction with the IShell­Folder it is associated with. In file-system speak, this is a "relative path."
    • ID­LIST_ABSOLUTE represents an item ID list relative to the desktop root folder. It too can be any length. This item ID list must be used in conjunction with the IShell­Folder returned by SH­Get­Desktop­Folder. In file-system speak, this is a "fully-qualified absolute path." (An absolute ID list is the special case of a relative ID list where the implied shell folder is the desktop root folder.)
    • ITEM­ID_CHILD_ARRAY represents an array of pointers to ITEM­ID_CHILD objects, where all of the ITEM­ID_CHILD objects are children of the same shell folder parent. The array must be used in conjunction with that parent shell folder.

    These new types were introduced to help catch common programming errors when using the shell namespace. For example, if you try to pass an array of absolute pidls to IShell­Folder::Get­UI­Object­Of, you will get a type mismatch compiler error because that method takes an ITEM­ID_CHILD_ARRAY, and the thing you passed is not an array of ITEM­ID_CHLD pointers.

    You are encouraged to turn on strict mode when compiling code that uses the shell namespace, but to preserve source code backward compatibility, the setting is off by default.

  • The Old New Thing

    Why do Explorer and the command prompt interpret file times differently?


    A customer observed that if they use Explorer to view the timestamp on a file, it is not always in agreement with the value shown if they run a plain DIR in a command prompt. They are sometimes off by an hour. Why is that?

    Whenever you hear the phrase "off by an hour" you should immediately think "Daylight Saving Time".

    The formatting of file timestamps shown by Explorer has changed over time. The most recent algorithm (at the time of this writing) is to use the time zone that was in effect at your current location at the time the timestamp was created. For example, a file created at noon in June 22 will show its timestamp as noon, even if you view it in the middle of December. That's because Explorer says, "Well, on June 22, Daylight Saving Time was not in effect, even though it's in effect now, so I will interpret that time zone as if Daylight Saving Time were not active." (Hey, Raymond, didn't you get that backward? Answer: The customer who asked this question is in New Zealand.)¹

    The old-style function for converting a UTC timestamp into a local timestmap is File­Time­To­Local­File­Time. The documentation for that function points you at the sequence of operations you need to perform if you want to use the time zone of the timestamp instead of the current time zone.

    Explorer switched to using the time zone of the timestamp, but the command processor continues using the old-style conversion.

    Why doesn't the command processor get with the program?

    Well, for one thing, the people who decide what Explorer does are not the same people who decide what the command processor does. (The Explorer folks can certainly make suggestions, but they can't force the command processor to do anything.) It's like asking why Taco Bell puts the men's room on the left, but Pizza Hut puts it on the right.

    The command processor is an old and cranky program. The command processor yells at Explorer to get off his lawn. The command processor gets upset when his Internet connection flakes out while he's watching Matlock online. The command processor doesn't care about your fancy-pants localized file names; it shows the raw file system names. The command processor has hundreds of thousands of scripts, and there's no way of knowing how many of them depend on the exact way it formats dates.

    You may be able to wheedle the command processor into making some changes for you, but you'd better have a really good reason, and he's going to be really grumpy about it. The command processor was once cajoled into changing its date format to four-digit years back in the late 20th century, and he did it only because everybody insisted that it was soooooooo important. But he was so grumpy about it, he had an option to go back.

    ¹ Actually, that's not true. The customer who asked the question was in Texas, but I moved him to New Zealand for the purpose of the story. People in the Southern Hemisphere always have to put up with us Northerners assuming that summer starts in June, so I figured I'd turn the tables for once.

Page 368 of 419 (4,184 items) «366367368369370»