[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box (try 2)
From:       Alexandre Julliard <julliard () winehq ! org>
Date:       2015-02-24 16:31:34
Message-ID: 871tlfqnix.fsf () winehq ! org
[Download RAW message or body]

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

> Am Dienstag, 24. Februar 2015 schrieb Alexandre Julliard:
>> Joachim Priesner <joachim.priesner@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@winehq.org


[prev in list] [next in list] [prev in thread] [next in thread]