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

[Alexandre Julliard]

Joachim Priesner <joachim.priesner at web.de> writes:

> 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).

OTOH if an app depends on some missing string (say a resource in a
builtin dll), seeing empty text will be a lot easier to figure out than
if you don't get the dialog at all.

-- 
Alexandre Julliard
julliard at winehq.org