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