Thanks for the suggestions, André, Erich, and Reece. Got a few more
ideas at least, though I still haven't found the answer.
Reece Dunn wrote:
The code above is using different methods to locate an IHlinkTarget
object, and then calling the Navigate method on that (and presumably
returning the HRESULT of that call, although the code listed does not
return anything).
I found this interesting, so investigated a bit more. I pulled out the
code path from MSDN with no IHlinkSite and no IHlinkBrowseContext (as my
HlinkNavigate call does). The test makes a moniker, binds its object to
an IHlinkTarget, and executes IHlinkTarget::Navigate.
On native, the test succeeds navigating to winehq.org. But
IHlinkTarget::Navigate returns S_OK, not 0x40100. So that probably
eliminates IHlinkTarget::Navigate as the source of the mystery value.
It was a good guess, anyway.
As near as I can tell, the "unwrapped" version in the test should have
all of the same information as the call to HlinkNavigate, but at no
point does 0x40100 appear.
Per Erich's suggestion, I tried a number of different flags to both
HlinkNavigate and IHlinkTarget::Navigate, but was never able to get
either to change their return values at all. On success, HlinkNavigate
always seems to return 0x40100.
NOTE: The test is incomplete (there are a lot of methods on the
interfaces that are returning E_NOTIMPL), especially the
QueryInterface and QueryService methods.
Yeah, I'm aware of that. Native doesn't seem to care, and just removing
the IHlinkSite reference entirely returns 0x40100 from HlinkNavigate anyway.
Finally, I've got a test for this which doesn't require any interaction
from the user, but will leave a browser window open after the test
finishes. Is this acceptable, or should I still leave it in a
"winetest_interactive" if statement?
Andrew
