On 1/24/11 6:11 PM, Erich Hoover wrote:
On Sun, Jan 23, 2011 at 11:32 AM, Jacek Caban<ja...@codeweavers.com> wrote:
On 1/20/11 6:40 PM, Erich Hoover wrote:
On Thu, Jan 20, 2011 at 4:00 AM, Jacek Caban<ja...@codeweavers.com> wrote:
+ ok(status& success_flag, "OLECMDID_STOP not enabled/supported:
%08x\n", status);
You could test the exact value here: ok(status == ...)
I was trying to avoid adding some conditional todo_wine calls
Hiding differences between Wine and Windows in tests is the worst thing you can
do. When one is trying to find a bug, tested parts of implementation are much
less suspicious than not or poorly tested. If you know about more such things
in the patch, please fix them. You don't write the test to pass on your
implementation. You write it to know the right implementation.
I would say that testing the mask is not about hiding differences, it
makes it clear that this particular test is meant to demonstrate
whether a specific feature is available. At some point you have to
make a trade-off between making a particular test completely
comprehensive or having it be clear exactly what is being tested.
See two second following comment.
In this particular component there are a lot of things that are not yet
implemented, so it's a little difficult to add a self-contained test
for a feature without it ballooning into a bunch of unrelated issues.
There are two other such "issues" I have become aware of with the
current implementation that could be added as tests, but I would say
that they both belong in separate patches (if you want them at all):
1) The IOleCommandTarget is cached when the WebBrowser is initialized
(rather than being requested each time it is used)
2) The document is initialized much earlier on native than it is in Wine
My goal here is to implement (as well as I can) a single feature that
I've had sitting in my stack of unsubmitted patches, I'm not trying to
implement everything in this component in one fell swoop. If that's
really what it's going to take to get this feature implemented then I
can take the time to implement more, but it'll take me a while and I'd
really like to move this item off of my plate so I can clean up some
of my other unsubmitted patches before they become too far out of
sync.
You're getting me wrong. I don't expect you to implement more, I don't
even expect you to implement these two APIs fully. I'm just saying not
to hide things you find during writing tests. That's what we have
todo_wine for.
(for some reason native does not respond with "supported", even though it
does in the mshtml tests), please see if you like the attached better.
Or it proves that it's not a simple forward to mshtml?
It's possible that they masked the supported flag out, especially
since all of the examples I've seen on MSDN check for the enabled flag
rather than the supported flag. However, I doubt that they
copy-pasted the mshtml code and then made changes to it. I'd say that
even if they did it'd be better to forward to mshtml and discover if
there are any differences (and where they are) as people test
applications that use this functionality.
Copy&paste wouldn't even work here. It's possible to implement this API
either on top of other, not IOleCommandTarget, APIs exported by
documents, not forwarding all of commands or conditionally forwarding.
I'm not saying your patch can't go into Wine the way you implement it,
but keep in mind that it may obviously fully correct.
We still have them in separated functions you've called test_QueryStatusWB and
test_ExecWB. We most likely will want more tests on WebBrowser instance without
container's IOleCommandTarget, and it would be nice if we could reuse
test_CommandTargetPassthru for that (well, the name would be better more
generic as well).
Sorry, for some reason I was a bit dense and didn't catch exactly what
you were planning here. Please see if the attached is more to your
liking, the test bot results are available here:
https://testbot.winehq.org/JobDetails.pl?Key=8575
I didn't catch earlier another problem here:
+ case OLECMDID_STOP:
+ CHECK_EXPECT(Exec_STOP);
+ return S_OK;
+ case IDM_STOP:
+ CHECK_EXPECT(Exec_STOP);
+ return OLECMDERR_E_NOTSUPPORTED;
Don't use the same DEFINE_EXPECT values for different calls. Also,
IDM_STOP wouldn't usually make sense here, it's supposed to be called
with CGID_MSHTML. It's fine for test's sake, but some comment would be
nice. Same for QueryStatus.
+ trace("Testing Full-Featured WebBrowser (no download)...\n");
+ test_WebBrowser_FullFeatured(FALSE);
+ trace("Testing Full-Featured WebBrowser...\n");
+ test_WebBrowser_FullFeatured(TRUE);
"Full-Featured WebBrowser" doesn't well explain what we are testing.
Let's keep existing messages and function name for existing code.
Jacek
