• The Old New Thing

    Where does an IT guy from a major hotel chain stay at the PDC?

    • 9 Comments

    I believe it was Marc Miller who related this story to me at the PDC. He was chatting with someone whose name badge identified him as an employee from a major high-end hotel chain. Marc joked, "Well, I think it's obvious which hotel you're staying at."

    "Oh no," the gentleman replied. "They won't let me stay there. Too expensive."

    [Raymond is currently away; this message was pre-recorded.]

  • The Old New Thing

    The difficult balancing act between customization and supportability

    • 9 Comments

    My colleague Kam VedBrat (from who I shamelessly stole the pictures of thse high-DPI displays in my PDC talk) discusses the difficult balancing act between customization and supportability. (Part II.) Note that decisions on this subject also also impact compatibility: Windows Vista greatly expands the palette of objects covered by the visual style. Any visual styles designed for Windows XP need to be revised in order to cover those new Windows Vista elements. Whose reponsibility would it be to revise them?

  • The Old New Thing

    Thread affinity of user interface objects, part 2: Device contexts

    • 9 Comments

    Last time, we discussed briefly the thread affinity rules that govern window handles.

    Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as GetDC must also be the one that calls ReleaseDC, but as with window handles, during the lifetime of the DC, any thread can use it. If you choose to use a DC in a multi-threaded manner, it's your responsibility to coordinate the consumers of that device context so that only one thread uses it at a time. For example, to host windowless controls across multiple threads, the host obtains a DC on the host thread, then asks each control in sequence to draw itself into that DC. Only one control draws into the DC at a time, even if the control happens to be on a different thread.

    The thread affinity of DCs is much more subtle than that of window handles, because if you mess up and release a DC from the wrong thread, things will still seem to be running okay, but the window manager's internal bookkeeping will be messed up and you may get a bad DC from GetDC a little later down the line.

    Next time, the remaining user interface elements.

  • The Old New Thing

    Using a physical object as a reminder

    • 8 Comments

    On our team, we have a mailing list where people can report problems. Those people could be testers from our team or they could be people from elsewhere in the company. Everybody on the team is expected to keep an eye on the messages and debug problems in their area. The job of monitoring the mailing list to ensure that every issue is ultimately addressed rotates according to a predetermined schedule, and in addition to receiving a piece of reminder mail at 4pm the business day before it's your turn, you will also find a Mickey Mouse ears hat on your desk when you arrive in the morning.

    I bought this hat in Disneyland a few years ago and somehow managed to convince the person operating the sewing machine to stitch the name "Dev O'Day" on the back. "It's an Irish name," I explained, but it also stands for "Developer of the Day", which is the title we use for the person who monitors the mailing list.

    One of our team members went on vacation to Disneyland the following year and brought back a back-up hat, which sits in my office. The back-up hat is occasionally brought into service when the primary Dev O'Day hat goes missing, at which point a Search and Rescue mission is undertaken to locate the hat and restore it to circulation. (It's usually just sitting in the office of someone who was Developer of the Day recently and merely forgot to hand the hat off at the end of the day.)

  • The Old New Thing

    The psychology of naming your internal distribution lists

    • 8 Comments

    One problem that I'm sure everybody has run into is what I'm going to call the "comp.unix.wizards" problem. People who have a problem with unix are looking for someone who can help them, and given the choice between a general questions group and a wizard group, they're obviously going to choose the wizards because that's where the smart people are! Of course, this annoys the wizards who created the group for focusing on advanced unix topics.

    Here's a trick I've seen used by more than one team: Give your non-technical distribution list the name "XYZ Technical Discussion". Meanwhile, name your internal team communication distribution list something less attractive like "XYZ Infrastructure Committee". Your "XYZ Technical Discussion" list will get the support questions, and people will feel like they're getting a "more direct line" to the technical staff. In reality, of course, the technical staff read both the "XYZ Technical Discussion" and the "XYZ Infrastructure Committee" groups. This is just a trick for keeping external support questions separate from internal team communication.

    (Now, by revealing this trick, I risk ruining it.)

  • The Old New Thing

    Bicycling from Mercer Island to Microsoft main campus

    • 8 Comments

    I asked four people who commute by bicycle eastbound over the I-90 bridge to Microsoft main campus what route they take, and they gave three different answers. I've given them meaningless names just to tell them apart.

    The yellow route

    First half (markers A1 through A5) | Second half (markers B1 through B5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Avoids downtown Bellevue
    Con: You're stuck on Bel-Red

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker A1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker A2).
    • Turn left (north). Bellevue Transportation Department recommends riding on west (left) side to reach bike path.
    • Turn right onto SE 8th St (marker A3) and go under I-405.
    • Cross Lake Hills Connector; the road name changes to SE 7th Pl.
    • Turn left onto 128th Ave SE (marker A4).
    • The road turns to trail after NE 7th St; turn right onto NE 8th St (marker A5 = marker B1).
      • Alternate route: Turn right onto Main St. and zig-zag through the neighborhood for a less hilly approach.
    • Turn left onto 132nd Ave NE or 134th Ave NE, depending on traffic (marker B2).
    • Turn right onto Bel-Red Road (marker B3).
    • Take Bel-Red Road to Microsoft main campus (markers B4 and B5).

    The blue route (two votes)

    First half (markers C1 through C5) | Second half (markers D1 through D5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Avoids downtown Bellevue and Bel-Red
    Con: Extremely hazardous intersection at the end

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker C1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker C2). Turn right (south).
    • Hazardous crossing - busy street, look both ways: Immediately after the underpass, turn left to get back on the I-90 trail (marker C3). Note: hill climb.
    • Cross Richards Road, ascend hill, turn left at 142nd Pl SE (marker C4).
    • Take the 142nd Pl bridge into Bellevue Community College and meander through the campus to 145th Pl SE (marker C5 = marker D1).
    • Turn right onto Lake Hills Blvd (marker D2).
    • Take Lake Hill Blvd across 148th, 156th, turning left onto 164th Ave SE (marker D3).
    • Follow 164th Ave SE until it ends at NE 30th St (marker D4).
    • Turn left and stop at Bel-Red Road (marker D5).
    • Extremely hazardous intersection. Cross Bel-Red, taking the back entrance to Microsoft main campus.

    You can avoid the hazardous intersection by taking a left onto NE 24th St. and turning right onto 156th Ave NE.

    The brown route

    First half (markers E1 through E5) | Second half (markers F1 through F5).
    Animated version: Click markers 1 through 5 in order then markers 1 through 5 in order.
    Pro: Overall low exposure to traffic
    Con: Tricky left turn in Factoria, extremely hazardous intersection at the end

    • Get to the I-90 bridge eastbound.
    • After crossing the bridge, stay on the trail when it twists under I-90; do not get off into the neighborhood. You will be on a trail parallel to SE Lake Rd (marker E1).
    • You will reach a fork in the trail. Bear right and take the bridge.
    • Ride through the park until the trail ends, putting you on 118th Ave SE (marker E2). Turn right (south).
    • Hazardous crossing - busy street, look both ways: Immediately after the underpass, turn left to get back on the I-90 trail (marker E3). Note: hill climb.
    • Turn left at Richards Road (marker E4).
    • Immediately after underpass, turn right onto Eastgate Way (marker E5 = marker F1). Note: hill climb.
    • Turn left at 161th Ave SE (marker F2).
    • When the road ends, turn right onto SE 24th St (marker F3).
    • Follow the road as it winds its way counter-clockwise around Phantom Lake; its name changes to 168th Ave SE and SE 16th St as it turns.
    • Turn right onto 164th Ave SE (marker F4).
    • Follow 164th Ave SE until it ends at NE 30th St (marker F5).
    • Turn left and stop at Bel-Red Road.
    • Extremely hazardous intersection. Cross Bel-Red, taking the back entrance to Microsoft main campus.

    As with the blue route, you can avoid the hazardous intersection by taking a left onto NE 24th St. and turning right onto 156th Ave NE.

    I haven't tried any of these routes myself since I live on the north side of town, and if I need to head to Mercer Island, I start from my house, not from work. Still, these are useful routes to know, so I'm recording them here for reference.

  • The Old New Thing

    Found blog: The Piehole

    • 8 Comments

    I have no idea who this person is, but she's all attitude all the time. Like this entry from October 18, 2005 when Jennifer was recovering from a foot injury:

    Men love a girl who can't run away quickly

    I got "wooey!"-ed by a garbage man on my way back to the office from lunch today... Because I'm so HAWT hobbling down the street. He could not resist my hobbling! I am hobbleicious! Sssssssss! *

    And just so you know, being followed down the street by a garbage truck with someone screaming "YEAH BABY!" and "what's your phone number?" is TOTALLY CLASSY!

    * This is the sound of me sizzling!

    It's the asterisk that's the icing on the cake.

    From that web site's blogroll you can springboard to a whole new world of outrageous content. Like My Boyfriend is a Twat or Inappropriately Dressed.

  • The Old New Thing

    Experiencing the world from flight level 210

    • 8 Comments

    Here are some airline-related web logs that I follow.

    • Fly with Me, a sort-of monthly podcast from a professional airline pilot. A glimpse into the world behind that cockpit door.
    • Flight Attendant Betty, another podcast, this one from your friendly flight attendant. (Though I have to admit, in Episode 2, I skipped over the disaster story and listened just to the stories of the world's stupidest hijackers.)
    • Yu Hu Stewardess, a flight attendant who isn't afraid to talk about all the stupid passengers she has to put up with (Do you recognize yourself?) and talk about what life is like when you spend a significant fraction of your nights away from home.
    • Doing Boeing, the web log of a Boeing database administrator. From the original technology company in the Seattle area.
    • The 777 Flight Test Journal. I had been looking for something to replace Randy Baseler's blog in my Boeing blogroll because Randy's was just all marketing hot air. The Flight Test Journal still feels a bit too heavily-managed, but it's a big improvement.

    Ry Jones recommends FlightAware, a web site for all your planespotting needs.

  • The Old New Thing

    The dangers of playing focus games when handling a WM_KILLFOCUS message

    • 8 Comments

    I had noted last year that WM_KILLFOCUS is the wrong time to do field validation. Here's another example of how messing with the focus during a WM_KILLFOCUS message can create confusion.

    Consider an edit control that displays feedback via a balloon tip. For example, password edit controls often warn you if you're typing your password while CapsLock is in effect. One of the things you probably want to do is to remove the balloon tip if the user moves focus to another control, since there's no point telling the user about a problem with something they aren't using. You might be tempted to subclass the edit control and do something like this:

    LRESULT CALLBACK EditSubclass(
        HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
    {
      switch (uMsg) {
      ...
      case WM_KILLFOCUS:
        if (hwndBalloonTip) {
          DestroyWindow(hwndBalloonTip);
          hwndBalloonTip = NULL;
        }
        break;
      ...
      }
      return CallWindowProc(prevWndProc, hwnd, uMsg, wParam, lParam);
    }
    

    When you give this code a shot, it works great... unless the user clicks on the balloon tip itself the edit control's caret (the blinking insertion point thingie) disappears. What happened?

    What happened is that you gummed up the focus change process by destroying the window that focus was going to! The focus change process goes like this:

    • Put focus on new focus window.
    • Send WM_KILLFOCUS to old focus window (if any).
    • Send WM_SETFOCUS to new focus window (if any).

    But in the second step, we destroyed the new focus window. When the focus window is destroyed, the window manager tries to find a new focus window, and it settles upon the edit control itself. This starts a recursive focus change cycle, telling the edit control that it now has focus again.

    Let's look at the flow in this nested focus change scenario when the user clicks on the tooltip window.

    • Put focus on tooltip.
    • Send WM_KILLFOCUS to edit control.
      • EditSubclass destroys the tooltip.
        • Window manager puts focus on the edit control.
        • Nobody to send WM_KILLFOCUS to.
        • Send WM_SETFOCUS to edit control.
          • EditSubclass passes WM_SETFOCUS to the original window procedure.
      • EditSubclass passes WM_KILLFOCUS to the original window procedure.
    • Send WM_SETFOCUS to tooltip - fails (tooltip was destroyed).

    Do you see the problem yet?

    Look at the message traffic as it reaches the original edit control window procedure:

    • WM_SETFOCUS (from the nested focus change)
    • WM_KILLFOCUS (from the original focus change)

    As far as the edit control is concerned, it gained focus then lost it. Therefore, no caret, since the edit control displays a caret only when it has focus, and your recursive focus changing has resulted in the edit control thinking it doesn't have focus even though it does.

    There are many ways out of this mess.

    First, notice that you don't need to subclass the edit control; you can just react to the EN_KILLFOCUS notification. Second, you can respond to the EN_KILLFOCUS by posting yourself a message and destroying the tooltip on receipt of that posted message. By doing it via a posted message, you avoid the recursive focus change since your work is now being done outside a focus change cycle.

  • The Old New Thing

    The Northwest Mahler Festival performs Mahler's Second Symphony ("Resurrection")

    • 8 Comments

    Last night I attended the Northwest Mahler Festival's performance of Mahler's Second Symphony (The Resurrection). The concert opened with Copland's El Salón México and Barber's Prayers of Kierkegaard. [Typo fixed 12:30pm]

    The Copland was kind of shaky, in a way that I couldn't quite put a finger on. The wind balance seemed a bit off, and it somehow didn't seem to "come together". By contrast, my knowledge of the Barber was zero, so they could've pulled out kazoos and I wouldn't've know that something was amiss.

    The Mahler demands quite a bit from both the woodwind and brass sections, but I was relieved to find that the tricky problem of getting them to play friendly appeared to be nonexistent. The Mahler "came together". (Well, duh, this is the Northwest Mahler Festival, after all.) I was so at ease with it that I started to ignore the occasional technical error...

    Performances of Mahler symphonies have a significant visual component. It's always a blast to see the clarinets playing "Schalltrichter auf", and for the Second, I was oddly fascinated by the rute. (I think my favorite Mahler percussion instrument is the "large hammer striking a wooden block" from the Sixth Symphony. When you see the percussionist raise that huge mallet, you know it's coming... and when the blow finally comes, it sends shock waves through your body.)

    Anyway, there's no real point to this entry. Just babbling about a symphony concert that I found very satisfying.

  • Page 380 of 453 (4,521 items) «378379380381382»