On 1/18/11 7:31 PM, Erich Hoover wrote:
On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban <jacek@codeweavers.com> wrote:
...
I'm not sure what you mean by "hijack the IOleCommandTarget". All we do is implementing client's IOleCommandTarget. It's something different from document's one.

I understand that, but apparently the native implementation (testing on the test bot WXPPROSP3) sends the command to the client IOleCommandTarget instead of the document IOleCommandTarget (at least under the conditions of the webbrowser tests).  That is what I mean by hijacking, the command is going to the "wrong" target.  My guess would be that there is some sort of priority mechanism, though I have no idea how it would work (except maybe "if there's a client/container then send to that target, else send to the document target).

That sounds reasonable.

  I've attached a test where I disabled the client/container, and you can see that it then gets passed through (QueryStatusWB will return success instead of passing through the client target and returning failure):
https://testbot.winehq.org/JobDetails.pl?Key=8408

Hmm, it means that another run of tests (at least required subset of existing test_WebBrowser) with client's IOleCommandTarget disabled would be interesting. Do you feel like writing it? Otherwise we'd need at least a FIXME in this case.

Jacek