TaskDialog implementation

[André Hentschel]

Am 11.06.2011 09:45, schrieb Hans Leidekker:
> On Fri, 2011-06-10 at 23:29 -0500, Vincent Povirk wrote:
>> Well, I think you may be right that changing it to E_NOTIMPL at this
>> point would break something and might be a bad idea. Sadly, Hans
>> didn't say what the stub was originally for. Hopefully, we'll soon
>> have a working implementation and it won't matter. ;) 
> 
> I added it for the Internet Explorer 9 installer but it has been
> broken already when someone changed it to return IDYES instead of
> IDOK in pnButton. I don't know which app that was for.
> 

Yes IE9 installer matters here and it's actually broken, so a working GUI implementation would be awesome.

Am 11.06.2011 01:37, schrieb Patrick Gauthier:
> What I seem to get from your input and reading SubmittingPatches, is
> basically "tests, tests, tests". I thought a while about "how does one
> automate tests on GUI stuff?" and "how can I ensure that my dialog
> renders right in a test, short of using a flaky thing like GetPixel()?",
> etc.
> 
> Then it came to me. What I will do is first change the implementation to
> return E_NOTIMPL as Vincent Povirk suggested. Then I will start writing
> tests that show use TaskDialogIndirect and sends a bunch of TDM_xxx
> messages and tests that the callback procedures receives all the right
> TDN_xxx notifications, at least. It won't be able to test that the
> dialog _displays_ right, but at least that it functions right from an
> API point of view. As long as I can close the dialog when done testing,
> the tests should not require any kind of user interaction.

Right, you can send messages and maybe also send keys but not GetPixel().
One interessting part is the returnvalue for various "bad" inputs like NULL for pointers and so on.
You can have a look at the user32 tests, maybe the file dlls/user32/tests/dialog.c is good to get inspired for some special things.

> Thing is, however, that I already got the full implementation written
> "as a block", short of "replaying my coding process", I don't see how I
> could efficiently do that. I could always make different patches for
> different parts, like, dialog creation, then layout, then message
> handling, etc, but you would not get a working TaskDialog until the last
> patch was integrated.

It should work as your existing implementation after all patches are committed.
Between the patches only the rules apply that Vincent just sent on that topic.

In short it means if you send e.g. 10 patches and progressbar patch is patch 6, then Wine shouldn't suffer after patch 1-5 applied like compilation errors or at runtime crashes and the tests should still apply.
But of course at this point a request to TaskDialog to display a progressbar won't show one, so it maybe should return E_NOTIMPL or something and print a FIXME.

-- 

Best Regards, André Hentschel