On 1/18/11 7:31 PM, Erich Hoover wrote:
On Tue, Jan 18, 2011 at 3:08 AM, Jacek Caban <jacek@codeweavers.com
mailto: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):
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