[PATCH 2/4] shdocvw: Implement IWebBrowser_ExecWB.
Jacek Caban
jacek at codeweavers.com
Wed Jan 19 14:05:00 CST 2011
On 1/18/11 7:31 PM, Erich Hoover wrote:
> On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban <jacek at codeweavers.com
<mailto:jacek at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110119/15bd3764/attachment.htm>
More information about the wine-devel
mailing list