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

[Vadim Zeitlin]

On Wed, 8 Feb 2023 22:53:30 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Perhaps there are really two type of applications

 I think reality is more complicated and not only there are more types, but
the same application might need both behaviours in different contexts.

GC> Or perhaps it's the file formats themselves that are divided between
GC> these two categories.

 This is probably true, but it's up to the application to decide how does
it want to handle these formats.

GC> >  After thinking about it for some time, I don't see any serious drawbacks
GC> > to adding some wxFD_ALWAYS_APPEND_EXTENSION flag and I guess it could make
GC> > a number of people if not happy, then less unhappy than they currently 
are.
GC> > 
GC> >  One problem is that lmi doesn't actually use wxFileDialog directly, but
GC> > only via wxDocument, so it would have no way of specifying it. But knowing
GC> > that docview applications are very much extension-oriented, as per above, 
I
GC> > think it wouldn't be a big stretch to start using the new wxFileDialog 
flag
GC> > in wxDocument::SaveAs() unconditionally.
GC> 
GC> Thanks. Would that flag affect the wxString argument that the wx
GC> doc/view framework passes to DoSaveDocument(), which lmi overrides?

 Yes, it will always get the actual path where the data should be saved, so
it will have the correct extension.

GC> This is not yet urgent for us: as far as we know, only one end
GC> user has windows-11, and the rest have windows-10. But eventually
GC> all will have windows-11.

 I've now installed Windows 11 in a QEMU/KVM VM here (it went much more
smoothly than when I tried to do it the last time, in fact I had no
problems at all -- other than having to deal with creating a Microsoft
account which is now required to be able to install the OS) but I can't
reproduce the problem there neither, see my latest comments in
https://github.com/wxWidgets/wxWidgets/issues/23193 and so now I'm even
more lost than before...

 However I still think I can fix it because I know what happens on the
affected machines thanks to PBfordev who has reproduced the problem. And we
also know of two other bugs in this area that he discovered: first one is
that if the entered file name ends with a period, then the extension is
still appended but with another period, resulting in two of them in the
final name, which is probably not ideal. Second one is even more
unexpected: using a "known" extension (and while I am not sure what a known
one is, but all of .exe, .pdf, and even .cpp are) disables appending the
extension specified by the filter too. So the current behaviour is even
less predictable than I thought.

 Finally, to return to wxGTK previously mentioned in this thread: it never
appends any extension at all, as wxGTK never calls AppendExtension(), so
this will have to be changed to support wxFD_ALWAYS_APPEND_EXTENSION in it.

 Regards,
VZ

pgpromMRlUIc2.pgp
Description: PGP signature