July, 2010

  • The Old New Thing

    No, you can't lock a gadget to the top of the sidebar


    In another installment of I bet somebody got a really nice bonus for that feature, I offer you this customer:

    My customer has created a Windows Vista sidebar gadget and wants to know if there's a way to force this gadget to appear at the top of the sidebar and prevent the user from moving or removing it.

    I applaud this company for having written the most awesome sidebar gadget in the history of the universe. It's so compelling that it should override the user's preferences and force itself into the upper right corner of their screen in all perpetuity.

    Unfortunately, Windows was not prepared for a program as awesome as this, and there is no supported way to force a gadget into a particular position and prevent the user from moving or removing it.

  • The Old New Thing

    Suggestion Box 4


    The topic backlog from Suggestion Box 3 has nearly cleared out, and I've actually been enjoying not having to write up a reply every Monday for the past several months, but all good things must come to an end, and so, without much fanfare, we now have Suggestion Box 4.

    Remember, the suggestion box is for suggestions for future topics. It isn't for developer support, bug reports, or ranting. Topics I'm inclined to cover:

    • Windows history (particularly the Windows 95 era).
    • Windows user interface programming in Win32, and shell programming in particular.
    • General programming topics (selectively).
    • Issues of general interest.
    • My personal hobbies.

    Topics I am not inclined to cover:

    • The blog software itself. You can visit the Community Server home page and cruise their support forums.
    • Internet Explorer. You can try the IE folks.
    • Visual Studio. You can try one of the Visual Studio blogs.
    • Managed code. This is not a .NET blog. I do not work on .NET technologies. As far as .NET is concerned, I'm just another programmer like you. Occasionally I touch a .NET-related topic (including the annual "CLR Week"), but I do not bring any inside expertise to the subject.
    • Non-software Microsoft topics, such as product support policies, marketing tactics, jobs and careers, legal issues.
    • Microsoft software that isn't Windows. (Exchange, Office, ...)
    • Windows topics outside user interface programming. (Plug and Play, Terminal Services, Windows Messenger, Outlook Express, SQL, IIS, remoting, SOA...)
    • User interface programming in anything other than Win32. (Because I know nothing about it.)
    • Debugging a specific problem. (Not of general interest.)
    • Predictions for the future. (What's the title of this blog again?)
    • Participation in Internet memes.

    Selected products at Microsoft participate in the Connect program, and many more have official blogs.

    Suggestions should be between two and four sentences in length. Think of it as an elevator pitch: You have three seconds to get your point across. Please also search the Web site first because your suggestion may have already been covered. (Possibly as a suggestion that was submitted to an earlier Suggestion Box that was not accepted.) And remember, questions aren't suggestions.

    The Suggestion Box will be open for only two weeks, and I will be much more selective about which one I choose to accept than in previous go-rounds. I'll answer one every Monday of 2012 (minus holidays and special events such as CLR Week), and once the end of the year is reached, that's the end of Suggestion Box 4.

  • The Old New Thing

    Management-speak: Multi-perspective content


    A colleague of mine visited an internal Web site for task ABC and found that the site was no longer there. Instead it was replaced with a simple message:

    Designed with the user in mind you will now find contextual ABC and DEF information served up in a secure format alongside all GHI information. Access to relevant multi-perspective content will enable faster resolution for your GHI needs.


    HTTP/1.1 301 Moved Permanently
    Location: http://ghi
  • The Old New Thing

    To enable and disable a window, use the EnableWindow function


    Commenter Chris 'Xenon' Hanson points out that fiddling with the WS_DISABLED style directly via Set­Window­Long leads to strange behavior. However it isn't the case that "most widget classes work fine." Reaching in and fiddling the style bit directly is like reaching into a program's internal variables and just changing the values: All the other work that is associated with changing the value simply doesn't happen.

    It's like taking a book you checked out of the library, re-shelving it, and then going into the library computer and marking it as "returned". The bookkeeping will say that the book has been returned, but all the other processes associated with a book return has not taken place: People who had placed a hold on the book aren't notified. The "number of books checked out" counter isn't updated. (Which gets interesting when you come to the end of your senior year and the system won't let you graduate because its records say that you still have 1 book outstanding, yet when you say "Show me all the books I have checked out" it returns no records.)

    In the case of windows, merely setting the WS_DISABLED style does not generate WM_ENABLE messages, it doesn't generate accessibility notifications, it doesn't do focus bookkeeping, all it does is set the flag and goes home. Eventually, some code will stop working because something "impossible" happened (in this case, a window transitioning from enabled to disabled without ever receiving a WM_ENABLE message).

    Similarly, the way to change a window's visible state is to use the Show­Window function and not to manipulate the WS_VISIBLE style directly.

    "I think I filed a suggestion on MSDN2.microsoft.com's suggestion box to advise people not to fiddle with the WS_DISABLED flag at runtime via Set­Window­Long() since it seems like a viable route if you don't know otherwise."

    Actually, the advice already exists right at the top of the Window Styles page where it says "After the control has been created, these styles cannot be modified, except as noted." And for WS_DISABLED, it says "To change this after a window has been created, use Enable­Window."

  • The Old New Thing

    How do I launch the Explorer Search window with specific search criteria?


    A customer wanted to know how to launch Explorer's Search window with specific fixed search criteria. It turns out that there are two ways of doing this, the poor man's way and the overachiever's way.

    The overachiever's way is actually easier to discover. You can use the search-ms protocol to generate a command string that describes the query you want to perform and pass it to Shell­Execute.

    The poor man's way actually requires a little bit of out-of-the-box thinking: Open the Explorer Search window and interactively create the query you want to be able to relaunch later. Now do File, Save Search, and save the query. When you want to relaunch the query, execute the saved search. This is, after all, how end users save and re-use searches.

  • The Old New Thing

    There's always the low-tech way of managing a process, too


    One of my colleagues had a problem with content management. I've changed the underlying scenario but the principle is the same.

    Is there a way to require that someone other than the author of a proposal sign off before the proposal tracking system accepts it? We had an issue where somebody wrote up a proposal, and due to a miscommunication, the proposal coordinator thought the proposal was ready and submitted it prematurely. This happened to another team in our group, and we want to make sure we don't make the same mistake.

    Another colleague explained:

    This is a people problem, not a technology problem. One way to work around it is to tell the proposal coordinator, "Don't submit the proposal until I sent you email that says it's okay to submit the proposal."

    I agree that this was a people problem, but the offered solution suffers from the same miscommunication problem as the original. The proposal coordinator might ask, "Is the proposal ready?" and the author responds, "It'll be ready tomorrow." The next morning, the proposal coordinator submits the proposal assuming that the author's response meant "Submit it tomorrow," when the author actually meant "You will get an email message from me tomorrow when it's ready."

    My colleague responded that the technique still has a single point of failure: An error by one person (the proposal coordinator or the proposal author—you decide who is at fault) results in the proposal to be submitted prematurely. We want to make sure two people sign off on the proposal before it is submitted.

    I proposed a method popularized by Henry Ford: The assembly line.

    • Author writes proposal. Places proposal in Location 1.
    • Proposal is reviewed by reviewer A. When it passes review, it is moved to Location 2.
    • Proposal is reviewed by reviewer B. When it passes review, it is moved to Location 3.
    • Proposal coordinator picks up proposals from Location 3 and submits them.

    With this scheme, every proposal must be approved by both reviewer A and reviewer B. If reviewer A fails to approve the proposal, then it remains in location 1. If reviewer B fails to approve the proposal, then it remains in location 2.

    This is another one of those simple low-tech solutions: Instead of putting all proposals (complete and incomplete) in one location, the location of the proposal represents its approval state.

    Of course, you can add more bells and whistles to this technique. For example, you can allow reviews in parallel by having Location 1 mean "unapproved", Location 2a mean "approved by reviewer A only", Location 2b mean "approved by reviewer B only", and Location 3 mean "approved by both reviewers." I'm sure you can come up with other tweaks. (I'm assuming that the proposal file format doesn't support custom fields like "signed off by".)

  • The Old New Thing

    Why don't all the Control Panel applications show up when you open a menu from the address bar?


    One of the features added to the Explorer Address Bar in Windows Vista is the ability to navigate quickly to an item by clicking on its name, or navigate to a folder's children by clicking the arrow that appears next to the item and selecting your destination.

    One customer reported that there appeared to be a problem with the Control Panel: Switch to Classic View, and then click the arrow next to the words Control Panel. The result is a dropdown menu that shows some but not all of the Control Panel applications. Is this a bug?

    No, everything is behaving normally. Recall that the dropdown menu shows things that you can navigate to; in other words, it shows you a list of subfolders of the Control Panel. Since you can't navigate to non-folders, they aren't listed as options.

    Notice, for example, that when you go to your Documents folder and click the dropdown arrow, not all of your documents show up in the menu. Only things which Explorer can navigate to appear in the menu (mostly subfolders but occasionally you'll find subfolder-like items such as compressed folders).

    The customer replied with a simple, "Thanks. That makes sense."

    Obligatory link: The so-called God Mode.

  • The Old New Thing

    Tips for planning your ship party


    Not saying how I know these things. Just making a little list for reference.

    • If you plan on staying dry, do not hold the party near a fountain. (Note that fountain avoidance is a necessary but not sufficient criterion.)
    • Corollary: If your team members have an armory of super soaker water cannons, and you plan on staying dry, then absolutely do not hold the party near a fountain.
    • Unrolled spools of bubble wrap are a poor choice of equipment when trying to climb from the lobby to the upper floor balcony.
    • After discovering that bubble wrap is unsuitable for climbing, do not upend a glass table in an attempt to gain a higher starting point.
    • A contest to see who can run and break through a plaster wall is not a recommended choice of impromptu amusement.
    • Do not throw a couch from the upper floor balcony. Not even if it's on fire.
    • Costco underwear does not count as swim trunks.
    • Do not have a tug of war over a vat of Jell-O.
    • The expensive sculpture outside your building is not a water storage tank in need of refilling.
    • Exercise caution when driving your motorcycle through the halls. The carpet damage from your burnout can be repaired, but the patches never really look the same.
    • On the day of the ship party, do not wear a nice suit. You might be thrown into the back of a pick-up truck and buried in ice.

    Bonus: Other lessons learned.

  • The Old New Thing

    What is the cost of WS_CLIPSIBLINGS if the sibling windows don't overlap?


    Commenter Robert May asks via the Suggestion Box whether there is a penalty to pay for using WS_CLIP­SIBLINGS when the sibling windows are not overlapping.

    When you use the WS_CLIP­SIBLINGS style, the window manager clips out the portion of the client rectangle that is covered by sibling windows. This is usually desirable behavior; otherwise you end up with two windows trying to paint at the same location, and somebody is likely to get hurt. (The One notable exception is in dialog boxes, where some controls like the group box were designed to have other controls drawn on top of them.)

    The cost of this flag is that when it comes time to calculate the visible region for a window, the space occupied by sibling windows higher in the z-order are clipped out. This happens even if the sibling windows don't overlap; after all, the only way to find out whether there are any overlapping sibling windows is to enumerate the sibling windows looking for them! Of course, if there is in fact no overlapping, then the calculations are trivial. The only cost was the loop which determines that there are no applicable siblings to be clipped out.

  • The Old New Thing

    What's the difference between LastWriteTime and ChangeTime in FILE_BASIC_INFO?


    The FILE_BASIC_INFO structure contains a number of fields which record the last time a particular action occurred. Two of the fields seem to describe the same thing.


    The time the file was last written to.


    The time the file was changed.

    What's the difference between writing to a file and changing it?

    I'm told that the difference is metadata. The Last­Write­Time covers writes to the file's data stream (which you accomplish via the Write­File function). On the other hand, the Change­Time also includes changes to the file metadata, such as changing its file attributes (hidden, read-only, etc.) or renaming the file.

    (And don't forget that Last­Access­Time updates are off by default now.)

Page 2 of 3 (28 items) 123