Here is another exercise in futility. Using the IE ActiveX (er, COM?) interface to automate Internet Explorer. I’ve got an app that navigates to a web page, but I don’t want it to leave an entry in the browser history list. Sounds simple enough. And hey look, there’s a flag you can pass to the IWebBrowser2.Navigate method: navNoHistory. Sweet!
I thought I was done in 10 minutes. But it turns out, that flag only pertains to the browser’s session history. Not the global history, which is where you see your link listed in the side-bar when you open the history list. Doh!
As usual, the docs are completely vague and unhelpful:
navNoHistory - Do not add the resource or file to the history list. The new page replaces the current page in the list.
Nothing about sessions versus global. And new page replaces the wha?
Ok, so I poked around some more and found another interface: IUrlHistoryStg. And look, it has a method: DeleteUrl. Well surely I’m done now. Not.
Ok. Here is what it says under More Information in that article:
DeleteUrl is not designed to delete the Internet Explorer History Shell folder entries.
Just great. The method to delete urls from the history folder is not designed to delete urls from the history folder. But wait…you can use this other method that requires 15x more lines of code, and pops up a dialog box which you can’t suppress. Just freaking brilliant!
Plan C: Wininet always has something. Yeah. Well, sort of. Ok, not really. <sigh> DeleteUrlCacheEntry yielded the same results: successful operation, but the history entry remained.
I should point out, the result codes for either of these methods indicated the operations were successful. I also tried feeding them bogus urls, to verify they would fail on bad data, and they did. So both IUrlHistoryStg.DeleteUrl and WinInet’s DeleteUrlCacheEntry will tell you they successfully deleted your url, but in fact didn’t.
Lovely.
I spent the better part of a day on this, by the way. I also tried traversing the cache and overwriting what was there, but none of it worked.
I should also point out, these Delete Url imposters may actually work, as according to the docs, when you delete a url, it is only flagged, and whenever the "cache scavenger" feels like getting off it’s lazy ass and doing its job, it will then actually delete the url. Anyone got an API call for "kick-the-lazy-ass-welfare-sucking-cache-scavenger-into-high-gear"??
But I digress. It might be nice if once in a while Microsoft could document their API’s as such: "DeleteUrl is a fictitious API that looks like it might do what you want it to do, but after you spend 3 hours testing it out, will actually turn out to do nothing but leave you feeling empty and jaded." Of course, if I ever read such an entry in the help file, I would probably spend the 3 hours finding out that it didn’t (er, did?) work as advertised. 
It always sucks when the docs are vague, but you can use the community content to beg for clarification. I’ve seen them respond in there and modify the docs from it a few times, so it may be worth trying. Won’t help in the short term though.
That’s a good point, I’ve seen that section but never thought to write to it.