IHlink::Navigate mystery value
Andrew Eikum
aeikum at codeweavers.com
Fri Jan 8 13:02:34 CST 2010
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
More information about the wine-devel
mailing list