• The Old New Thing

    My friend lived in a tiny house with an enormous garage

    • 5 Comments

    One evening, I had a series of three dreams. In each one, I visited an unusual home.

    In the first dream, I visited the home of a friend of mine. But instead of living in his condominium in the city, he lived in a house built into the side of a cliff.

    The house commanded a breathtaking view of the valley below, but the living quarters weren't very large. This was to his liking. "Moving in didn't take long." The top floor was a single room the size of a typical bedroom. The bottom floor was half that size.

    There was a six-inch-square mesh of wire covering the downstairs walls. "That lets the dog roam freely downstairs, but when he goes upstairs, he has to stay on the path."

    Also downstairs was the combination garage/shower room, a sleek, empty, 6000-square-foot space in dusky slate blue. You open the faucet, and water gently rains down from the ceiling. Now you and your 1000 closest friends (?) can shower together. And the car gets cleaned, too!

  • The Old New Thing

    There's no seating up there, so you just have to hang on for dear life

    • 5 Comments

    I dreamed that through a friend, I got to join a handful of other people atop Prince Charles's carriage as it wound its way through London. There was no seating up there, so you just have to hang on for dear life. When we reached Buckingham Palace, the assembled crowd and reporters swarmed the carriage for an opportunity to meet the Prince. This provided a sufficient diversion to allow us to climb down from the roof and sneak into the palace undetected.

    We've come to the end of the year, so that's all for Monday dream blogging. For those of you who hated it: You can uncover your eyes now.

  • The Old New Thing

    Tweeting Too Hard: Best of Twitter

    • 5 Comments

    We had Best of Craig's List.

    We had Lamebook.

    Now we have Tweeting Too Hard, "where self-important tweets get the recognition they deserve."

    Examples:

    The people who say I'm arrogant and shallow don't see me when I'm at home with my wife. Did I mention that she's a former swimsuit model?
    How was it I got invite to last yrs White House Xmas party when Bush was prez; and nothing this year? I guess I must try harder 2 be fab.
  • The Old New Thing

    Crazy Eddie: His prices were insane because it was all a criminal operation

    • 5 Comments

    If you lived in the New York metropolitan area in the 1980's, you couldn't avoid the advertisements for electronics store Crazy Eddie. What I didn't realize until now was that the retail establishment was a criminal operation from day one. Sam Antar, Crazy Eddie CFO, and nephew of company namesake Eddie Antar, talks us through the entire operation in this riveting interview. Along the way, you'll learn why it was at first advantageous to under-report revenues, then later why it became advantageous to return the unreported money back to the system.

    Unexpected skill you develop as a money launderer: You can look at a bag and immediately calculate how much cash will fit in it.

    Other Planet Money podcasts I found interesting:

  • The Old New Thing

    The great thing about naming conventions is that not everybody will follow them

    • 5 Comments

    The naming convention for HRESULT is «facility»_«severity»_«name», where the facility portion (and the underscore) is omitted if the facility is FACILITY_NULL or FACILITY_WIN32.

    Good luck finding anybody who follows this naming convention.

    Okay, fine, if you look closely you might be able to find some people who do.

    COM   CO_ E_ NOTINITIALIZED
    CO_ S_ MACHINENAMENOTFOUND
    Structured storage   STG_ E_ SHAREVIOLATION
    STG_ S_ CONVERTED
    SETUPAPI   SPAPI_ E_ EXPECTED_SECTION_NAME
    Data and view   DV_ E_ TYMED
    DV_ E_ FORMATETC
    Class factory   CLASS_ E_ NOAGGREGATION
    Class registry   REGDB_ E_ CLASSNOTREG
    OLEDB   DB_ E_ DELETEDROW

    Actually, I guess I was a bit too pessimistic when I said nobody follows it. It seems that the majority of Windows components do follow this convention, although there are some notable exceptions.

    DirectDraw   DDERR_UNSUPPORTEDFORMAT
    ADSI   E_ADS_INVALID_DOMAIN_OBJECT

    There are also some people who decided to confuse matters further by using the HRESULT convention for error codes returned by GetLastError()!

    RPC   RPC_S_OBJECT_NOT_FOUND
    SmartCard   SEC_E_SMARTCARD_CERT_REVOKED
    Task scheduler   SCHED_E_SERVICE_NOT_LOCALSYSTEM
    Winsock   WSA_E_NO_MORE

    I apologize for the confusion this has caused.

    Pre-emptive clarifying remark: The examples given in this article are merely illustrative and are not intended to be comprehensive.

  • The Old New Thing

    Restating the obvious about the WM_NOTIFY message

    • 5 Comments

    It appears that people seemed to appreciate restating the obvious about the WM_COMMAND message, so I'll try it again with the WM_NOTIFY message.

    The WM_NOTIFY message is typically used by a control to communicate with its parent, either to provide information, request it, or both. Although that is the typical use, there are exceptions. For example, property sheets send the WM_NOTIFY to their children. Property sheets are this sort-of backwards model, where the common controls provide the parent window (the property sheet) and applications provide the child windows (the property sheet pages). The window manager doesn't care who sends the message to whom, as long as the sender and recipient are in the same process.

    The message cannot cross a process boundary because WM_NOTIFY is basically a sender-defined version of WM_USER. Anybody can define a new notification code and associate it with any structure they want (as long as the structure begins with a NMHDR). The window manager can't marshal the structure between processes because the structure is defined by the control, not the window manager.

    A little elaboration of that "sender-defined version of WM_USER": As we saw, the meaning of WM_USER messages is determined by the implementor of the window class. In other words, the code receiving the message decides what WM_USER means. That works great if you're some external code that wants to send a message to a known window class. But what if you're external code that wants to send a message to an unknown window class? For example, you're a list view control and you want to tell your parent about some event. You want to send a message to the parent window, but which message? You can't send anything in the WM_USER range because each parent window defines independently what those messages mean, and it's highly unlikely that all the parent windows are going to agree that WM_USER+205 means the same thing. For similar reasons, the WM_APP range is no good. A registered message would work, but if you have hundreds of potential events, then a hundred registered messages is a bit heavy-handed. The old-school answer to this was the WM_COMMAND message, whose notification code is defined by the sending control. Unfortunately, the notification code is all you get; the other parameters are busy doing other things. Enter WM_NOTIFY, which is basically WM_COMMAND on steroids: The NMHDR structure contains everything that was in the WM_COMMAND message, and since it's a structure, you can embed the NMHDR inside a larger structure to provide (and possibly receive) more information.

    Okay, end of strange digression.

    The NMHDR structure itself is a convention, in the same way that the parameters to WM_COMMAND are a convention. The hwndFrom member is supposed to be the control that generated the notification, but there's no enforcement.

    First, there's no way to enforce it. A window doesn't send a message; code sends a message. You can check the thread that is executing the code that is sending a message, but you don't know which window that code is associated with.

    "Well, the window that is sending the message is the one that most recently received a message."

    That doesn't work because you can have code associated with one window call code associated with another window without actually sending a message. In fact, you probably do this all the time:

    class CFrame : public CWindow {
    ...
     LRESULT OnCommand(...);
    ...
     CGraphWindow *m_pwndGraph;
    };
    
    LRESULT CFrame::OnCommand(...)
    {
     switch (idFrom) {
     case IDC_CPU: // user clicked the "CPU" button
      m_pwndGraph->ChangeMode(CPU); // change to a CPU graph
      ...
    }
    

    Suppose that CGraphWindow::ChangeMode function calls SendMessage as part of its processing. Which window "sent" this message? Since you have the power to read code, the message was conceptually sent by CGraphWindow, but the most recently received message is a WM_COMMAND sent to the frame window.

    Your method call is just a transfer of control inside your program. The window manager doesn't know what's going on. All it knows is that it delivered a WM_COMMAND message to the frame window, and then some mystery code executed, and the next thing you know, somebody is sending a message. It doesn't have the source code to your program to know that "Oh, that's coming from CGraphWindow::ChangeMode, and to get the window handle for CGraphWindow, I should call CGraphWindow::operator HWND()." (And even if it did, imagine your surprise when your breakpoint on CGraphWindow::operator HWND() gets hit because SendMessage called it!)

    Second, even if there were some psychic way for the window manager to figure out which window is sending the message, you still wouldn't want that. It is common for WM_NOTIFY handlers of complex controls to forward the message to another window. For example, the list view control in report mode receives WM_NOTIFY messages from the header control and forwards them back out to its own parent, so that the list view parent can respond to header notifications. (The parent normally should just let the list view handle it, but the operation is performed in case you're one of those special cases that needs it.)

    Okay, back to what the fields of NMHDR mean. There are only three fixed fields to NMHDR and they pretty much match up with the parameters to WM_COMMAND:

    • hwndFrom is the handle to the window that is the logical source of the notification.
    • idFrom is the control ID corresponding to the window specified by hwndFrom. In other words, idFrom = GetDlgCtrlID(hwndFrom).
    • code is the notification code. The meaning of this notification code depends on the window class of hwndFrom.

    It is an unwritten convention that the notification codes for the common controls are all negative numbers. This leaves positive numbers for applications to use for their own purposes. Not that applications strictly speaking needed the help, because the meaning of the notification code depends on the window that generated the notification, so if you want a brand new 32-bit message number namespace, just register a new window class, and boom, a whole new range of codes becomes available just to you. (Even though the notification code values do not need to be unique across window classes, the common controls team tries to keep the system-defined notification codes from overlapping, just to make debugging easier.)

    The idFrom member is provided as a convenience to the window receiving the message so that it can use a simple switch statement to figure out who is sending the notification.

    Once you figure out which notification you're receiving, you can use the documentation for that notification to see which structure is associated with the notification. This answers Norman Diamond's complaint that he couldn't figure out what to cast it to. For example, if the notification is LVN_ITEMCHANGING, well, let's see, the documentation for LVN_ITEMCHANGING says,

    LVN_ITEMCHANGING
    pnmv = (LPNMLISTVIEW) lParam;

    pnmv: Pointer to an NMLISTVIEW structure that identifies the item and specifies which of its attributes are changing.

    In other words, your code goes something like this:

    case LVN_ITEMCHANGING:
     pnmv = (LPNMLISTVIEW) lParam;
     ... do stuff with pnmv ...
    

    I'm not sure how much more explicit the documentation could be made to be. All it was missing was the word case in front.

  • The Old New Thing

    The format rectangle is recalculated whenever the window resizes, and that's a good thing

    • 5 Comments

    Reader asmguru62 asks why a custom format rectangle of a multi-line edit control is lost when the edit control is resized. That's right, the format rectangle is recalculated whenever the window resizes, and that's a good thing.

    Imagine if it weren't recalculated. You create a multi-line edit control. Like many programs, you might create it at a temporary size while you try to figure out what its real size should be. You might even resize the control dynamically as the container is resized. (After all, everybody wants resizable dialogs.) What you definitely don't want is the format rectangle of the edit control to be locked to the size the window was originally created at.

    "Well, yeah," asmguru62 says, "sure that may be desirable if the application is using the default margins, but if the margins have been customized, then shouldn't those margins be preserved?"

    First, who says that your call to EM_SETRECT was to established fixed-size margins? All the function knows is that you said "Put the text inside this rectangle." It has no idea how you computed that rectangle. Did you subtract a fixed number of pixels? Did you use a percentage? Did you set the rectangle to force the text into a rectangle whose width and height form the golden mean?

    Second, if you want to set the margins, then set the margins. The EM_SETMARGINS message lets you specify the size of the left and right margins of a multi-line edit control. The edit control will take your margins into account when it recalculates its format rectangle after a resize.

    In other words, EM_SETRECT is the low-level function that lets you manipulate the edit control's internal formatting rectangle, the same rectangle that the edit control itself manipulates in response to the things that edit controls naturally respond to. There is no fancy inference engine here that says, "Let me attempt to reverse-engineer how this rectangle is related to the client rectangle so I can carry forward this computation when I recalculate the format rectangle." Think of it as reaching in and directly whacking one of the edit control's private member variables.

    If you want something higher-level, then use EM_SETMARGINS.

  • The Old New Thing

    Freudian typo: The accidental emoticon

    • 5 Comments

    Some time ago, I ran across the following Freudian typo in a mail thread discussing plans for the project after Milestone 3, commonly abbreviated M3.

    I'd like to talk with you about your plans for this area after <3.

    On the US-English keyboard layout, the M and comma keys are adjacent, and a shifted comma is a less-than sign. A simple off-by-one-key typo resulted in M3 turning into an emoticon.

  • The Old New Thing

    Microspeak: Net out

    • 5 Comments

    It started out in finance, but the term has crept into more mainstream usage (at least within Microsoft) and along the way picked up its own meaning:

    Where did we net out on this?
    Customers want you to net out the business value.
    Note any significant changes to the forecast and explain the reasons why. Net out changes to start conversation.

    Include the following points in your presentation:

    1. ...
    2. Net out action plan moving forward

    The next citation is a bullet point from a PowerPoint slide:

    Agenda
    Each district/vertical will answer/report back on:

    • ...
    • Net out top 3 business asks

    (I also have some finance citations, but they aren't relevant to Microspeak, so I've left them out.)

    In finance, to net out is to cancel out positive and negative amounts. For example, you might net out an account by cancelling amounts owed against amounts due in order to eliminate offsetting transactions. When calculating tax liability, you net out your gains against your losses to determine your net change for the tax period.

    In Microspeak, well, I'm not sure what it means. In that first citation, it appears to be a synonym for come to a conclusion. The question appears to be a rephrasing of "What was our conclusion on this?" or "What did we finally decide on this?"

    In the second citation, it appears to be a synonym for summarize in terms of net benefit/loss. "Customers want you to show the net benefit of the product."

    In the third citation, it appears to be used merely to mean summarize.

    And in the final two citations, it appears to be simply a verb meaning to produce.

    Note that net out is unrelated to that other Microspeak phrase net net, discussed earlier.

  • The Old New Thing

    A Few Seconds of Panic: Life as an NFL kicker

    • 5 Comments

    Although I don't follow him regularly when he appears on All Things Considered and didn't when he wrote for The Wall Street Journal, I'm a quiet fan of Stefan Fatsis's books because he writes about joining a world most of us don't get to see. I previously wrote about his excursion into the world of competitive Scrabble. Today, it's his book A Few Seconds of Panic, or more formally, A Few Seconds of Panic: A 5-Foot-8, 170-Pound, 43-Year-Old Sportswriter Plays in the NFL, another example of the Catchy title: Long boring subtitle book title fad. [Update: Now available in paperback.] Fatsis convinces a professional football team to let him join them for a pre-season game as a place kicker. From there, he observes the working of an NFL team from the inside. NPR's Only a Game interviewed him in August 2008. [mp3]

    (Fatsis is a regular member of Slate's new weekly sports podcast Hang Up and Listen. He mentions his kicking career only every other podcast now.)

    (And I wasted far too much time on what is rumored to be another Stefan Fatsis production, Name of the Year. Here's a list of previous winners.)

Page 382 of 419 (4,188 items) «380381382383384»