[3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box (try 2)

[Joachim Priesner]

Am Dienstag, 24. Februar 2015 schrieb Alexandre Julliard:
> Joachim Priesner <joachim.priesner at web.de> writes:
> 
> > Am Dienstag, 24. Februar 2015 schrieb Alexandre Julliard:
> >> There shouldn't be any need to distinguish. If you get 0 then there's no
> >> defined string and you use the fallback.
> >
> > Windows makes that distinction though:
> >  - String of length zero: TaskDialogIndirect succeeds, but no text is displayed for that parameter
> >  - Invalid resource: TaskDialogIndirect fails with ERROR_RESOURCE_NAME_NOT_FOUND
> 
> This is broken behavior, I don't see much point in reproducing this
> (unless of course you can find an app that depends on it).

I'd argue that a) the goal of "bug-for-bug" compatibility is really easy to achieve in this case and b) it saves debugging time in the long run should there be an application that does rely on it (even if only accidentally).

But I'm fine with just ignoring invalid string resources (instead of returning failure), which should be the "safe" variant.