Re: [lmi] File extension not added--common "save" dialog in msw11

[Vadim Zeitlin]

On Fri, 10 Feb 2023 02:52:53 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2/10/23 00:19, Vadim Zeitlin wrote:
[...]
GC> >  Finally, to return to wxGTK previously mentioned in this thread: it never
GC> > appends any extension at all, as wxGTK never calls AppendExtension(), so
GC> > this will have to be changed to support wxFD_ALWAYS_APPEND_EXTENSION in 
it.
GC> 
GC> Thanks. I'll test it when you consider it ready.

 I'm awfully sorry, but please forget everything I wrote in this thread
before because it turns out that I had completely misunderstood the issue.
I believe I do understand it now, but I'm much less sure about what to do
about it, so please let me restart this discussion from the beginning:

 What lmi user observed was a banal bug introduced (in the interest of full
disclosure: by my own changes due to improving unrelated aspects of the
file dialog implementation) in wxWidgets relatively recently and which was
present in 3.2.0 and the very close to it version of wxWidgets that lmi
currently uses. This bug was already fixed back in October 2022 and is not
present any longer neither in master nor in the just released wx 3.2.2. To
be totally clear, the bug was not specific to Windows 11 (I still can't
explain the "only with windows-11, not with windows-10" part of the
original report, but I strongly suspect it was a mistake) nor did it have
anything to do with One Drive or anything else outside of the program and
it simply always prevented the native file dialog from appending the
extension on all Windows versions. The fix was to let the native dialog do
it again, just as it always did before.

 So, if we upgrade lmi wx submodule to 3.2.2, as I plan to do, it should
behave correctly in the sense that it would behave the same as all the
other MSW applications and also in the same way lmi itself behaved before
(let me call this "standard behaviour"). IMO this should be satisfactory
and we should just do this and nothing else.


 However, while chasing this bug (which I thought was something completely
different and Windows 11-specific because people reported that it happened
only there and not under Windows 10 -- but it turns out that this was a
testing mistake), I've discovered a few things I hadn't know before, see
https://lists.nongnu.org/archive/html/lmi/2023-02/msg00008.html but, to
summarize:

1. Standard behaviour is more surprising than I thought, and doesn't append
   the default extension if the entered file name uses a "known" extension,
   where "known extensions" include possibly unexpected ones such as ".cat"
   and ".dpg".

2. Microsoft Excel, at least in the ancient version that I tested, doesn't
   conform to the standard behaviour but does its own -- and buggy -- thing
   resulting in a possibility of silently overwriting an existing file,
   which is, IMO, a much worse problem than the one originally described.


 So, on one hand, it might make sense for lmi to behave as Excel, but OTOH
it also seems to make sense to behave as 99% of the other programs on the
system (which, I'm sure, just use the native file dialog without overriding
its extension-appending logic, as weird as it is). And by not appending the
extension ourselves, we avoid the problem with showing the "Are you sure
you want to overwrite?" prompt after dismissing the dialog, and having to
show the dialog again if the answer is negative, which is not very
user-friendly (currently, this question is asked by the dialog itself,
while it's still shown, and if the answer is negative, the file dialog
remains shown).

 Hence the question: do you think standard behaviour is good enough or do
you still think that we need to add wxFD_ALWAYS_APPEND_EXTENSION, even
though this will make lmi behave differently than the other MSW programs
and the absence of this flag had never seemed to be a problem in the past
(but, theoretically, i.e. if lmi users use file names ending in ".cat",
could be)?

 Please let me know what do you think and sorry again for all the confusion
in this discussion, I was completely misled by the belief that this was a
different Windows 11-specific problem and not the one I had already fixed.
And while my failure to reproduce it should have been a clue, it just
confused me even more instead. Sorry!

VZ

pgpulTqBkYEUX.pgp
Description: PGP signature