Hi Erich,
On 1/15/11 12:14 AM, Erich Hoover wrote:
Real Name: Erich Hoover Description: Adds support for the IWebBrowser(2)_ExecWB function by passing the requested operations through to IOleCommandTarget_Exec. With this patch (and patch 1) the print button in hhctrl.ocx operates properly. ChangeLog: shdocvw: Implement IWebBrowser_ExecWB.
+ IOleCommandTarget* target; + HRESULT hres; + + TRACE("(%p)->(%d %d %s %p)\n", This, cmdID, cmdexecopt, debugstr_variant(pvaIn), pvaOut); + + hres = IUnknown_QueryInterface(This->doc_host.document,&IID_IOleCommandTarget, (LPVOID*)&target);
document may be NULL here.
+ if(FAILED(hres)) + return hres; + hres = IOleCommandTarget_Exec(target, NULL, cmdID, cmdexecopt, pvaIn, pvaOut); + IOleCommandTarget_Release(target);
Please write a test case for this. MSDN seems wrong in this case. It indicates in one place that we should use CGID_MSHTML as group GUID, and NULL in the other. The test should make it clean, which version is true.
Jacek
On Sun, Jan 16, 2011 at 1:01 PM, Jacek Caban jacek@codeweavers.com wrote:
On 1/15/11 12:14 AM, Erich Hoover wrote:
...
- hres = IUnknown_QueryInterface(This->doc_host.document,&IID_IOleCommandTarget, (LPVOID*)&target);
document may be NULL here.
Sorry, I'll take care of that.
- hres = IOleCommandTarget_Exec(target, NULL, cmdID, cmdexecopt, pvaIn, pvaOut);
Please write a test case for this. MSDN seems wrong in this case. It indicates in one place that we should use CGID_MSHTML as group GUID, and NULL in the other. The test should make it clean, which version is true.
I've looked into trying to do this test case and I'm at a bit of a loss. It appears that whatever I try to do the "webbrowser" tests hijack the IOleCommandTarget, so I'm not really testing what the "real" target does. It instead calls the test-specific OleCommandTarget_QueryStatus, though that test does not report any error on the ever-so-significant line: ok(!pguidCmdGroup, "pguidCmdGroup != MULL\n");
On a side note, do I need to resend the other two patches in that set? They are not dependent on this patch.
Erich Hoover ehoover@mines.edu
On 1/17/11 9:28 PM, Erich Hoover wrote:
On Sun, Jan 16, 2011 at 1:01 PM, Jacek Cabanjacek@codeweavers.com wrote:
Please write a test case for this. MSDN seems wrong in this case. It indicates in one place that we should use CGID_MSHTML as group GUID, and NULL in the other. The test should make it clean, which version is true.
I've looked into trying to do this test case and I'm at a bit of a loss. It appears that whatever I try to do the "webbrowser" tests hijack the IOleCommandTarget, so I'm not really testing what the "real" target does. It instead calls the test-specific OleCommandTarget_QueryStatus, though that test does not report any error on the ever-so-significant line: ok(!pguidCmdGroup, "pguidCmdGroup != MULL\n");
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.
On a side note, do I need to resend the other two patches in that set? They are not dependent on this patch.
Probably yes.
Jacek
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). 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
Erich Hoover ehoover@mines.edu
-
Erich Hoover -
Jacek Caban