An anonymous commenter asked why the Tab key doesn't select items from the auto-complete drop-down list. The answer: Because that key already has some other meaning.

The Tab key is used to navigate among controls in a dialog box. Adding auto-complete behavior to an existing dialog would disturb the tab order, which would in turn frustrate people who had "muscle-memorized" their way through the system. Instead of, "Ctrl+O text Tab Space Enter", it's "Ctrl+O text ... um... try to get the auto-complete drop-down to go away so the Tab key will take you to the next radio button, then hit Tab, Space, Enter."

If the auto-complete drop-down list were attached to a control in a dialog box, say, the edit box in the Start menu's "Run" dialog, then it wouldn't be possible to tab from the edit box to the Browse button or the OK button. Even worse, notice that the drop-down box covered the OK, Cancel and Browse buttons, so you can't use the mouse to click on them. And since you can't see them, you can't see what their accelerator key is.

That said, if you really want the Tab key to select items from the auto-complete drop-down, you can pass the SHACF_USETAB flag to the SHAutoComplete function. It appears that Internet Explorer's Open dialog passes this flag, because the scenario I described above actually happens when you want to open a web page as a Web Folder. You type Ctrl+O to open the Open dialog, type the URL, and then grf urgh can't get to the "Open as Web Folder" check-box...

As for the problem of not remembering its original size: The naive solution can cause more problems than it fixes. Suppose you preserve the size of the drop-down box on Internet Explorer's Address bar. Now the user resizes the window. Does the drop-down box keep its original size? Or does it resize by some mysterious algorithm to "match" the new size of the Address bar? What if the user runs the program after changing the screen resolution to 640×480 and the drop-down becomes bigger than the screen? If you keep the saved size, the resize gripper will end up off the edge of the screen. What if there are two Internet Explorer windows on the screen; should resizing one Address bar drop-down result in the other one changing to match? I'm not asking for answers to these questions. I'm just pointing out that in many cases, coding up a "fix" is the easy step. Designing the fix is the hard step. And then testing the fix with real users may force you to go back and reconsider your original design. Eventually, you spent three weeks fine-tuning this tiny feature. Could that time have been better-spent on some other feature that has greater impact? (Not to mention all the Slashdotters who would say, "Everybody who is working on these tiny features should be punished and told to work on security instead!")