Holy cow, I wrote a book!
An anonymous commenter asked
why the Tab key doesn't select items from the auto-complete
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
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"
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
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!")