MSHTML autocomplete in ATL/C++, no .NET

When hosting the webbrowser control directly, autocomplete works just fine. When hosting the mshtml control directly, autocomplete does not seem to work. Anyone have an idea on what the host needs to do to get the mshtml control to use autocomplete on forms. I have set the host's IDocHostUIHandler's DocHostFlags to DOCHOSTUIFLAG_ENABLE_FORMS_AUTOCOMPLETE and also fooled with OptionKeyPath, but haven't gotten anywhere. Another option might be to subclass the edit window in the document, implement my own autocomplete object, and use SHAutoComplete on the edit window. That seems like overkill though. Any help is appreciated. Thanks.
Who is Participating?
KurtVonConnect With a Mentor Commented:
Yeah, I knew #1 wasa long-shot, but it was pretty much the only way this was going to work easily.  IDocHostUIHandler2 does have a GetOverrideKeyPath, but if the correct location is being read there is no point in worrying about it.

There is probably an interface for the autocomplete callback that needs to be implemented.  I'm surprised it isn't handled in IDocHostUIHandler to be honest, since that is the interface that reports the capability.  I haven't been able to track down any documentation on it, though, so I suspect this is one of Microsoft's secret interfaces  you need to sign an NDA to find out about.  Certainly nothing obvious.

Sorry.  Maybe someone with insider information will pipe up.
Hopefully someone else can give you a more definitive answer, but rather than leave you hanging, here's what I see:

Internet Explorer 5 or later. This flag enables the AutoComplete feature for forms in the hosted browser. The Intelliforms feature is only turned on if the user has previously enabled it. If the user has turned the AutoComplete feature off for forms, it is off whether this flag is specified or not.

So setting the flag is not going to do any good when the option is disabled, and you will need to make sure the option is active.  This tells me one of two things:

1) It is possible that the option is read by the program controlling the mshtml control.  In that case, when hosting the webbrowser control, the webbrowser control reads the option from the normal IE registry settings, but when your program runs the html control directly the option is read from a different location.  Not very likely, but possible.

2) More likely, the autocomplete feature is actually implemented in the webbrowser control and you are missing a (possibly undocumented) callback needed to do autocomplete.  If this is true then SHAutoComplete will probably not work either (give it a try to see if this is a possibility though, it can't hurt).

I suspect #2 mostly because the IDocHostUIHandler docs say that it enables WebBrowser control features, not mshtml control features.

Hope this helps.

jweston1Author Commented:
Thanks for your response.  The IDocHostUIHandler::GetOptionKeyPath is called by the mshtml control, and uses the default registry settings at HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer if the function returns S_FALSE or the key is NULL. My default settings already have autocomplete on, so I don't set a new OptionKeyPath. Also, the DOCHOSTUIFLAG_ENABLE_FORMS_AUTOCOMPLETE flag works with the webbrowser control, but not with the mshtml control. As for SHAutoComplete, I realized I can't call it since the html edit box is not a window. So, I am thinking that the mshtml control doesn't support autocomplete.
All Courses

From novice to tech pro — start learning today.