Apache OpenOffice (AOO) Bugzilla – Issue 81318
The extension is not automatically removed by export dialog.
Last modified: 2007-09-13 06:44:52 UTC
To reproduce the problem the office should be correctly installed on windows with system integration ( no development installation ) - load a document ( for example test.ods ) - do export to pdf ( not important in which way ) - the export dialog suggests the document name "test.ods" The problem is dangerous in case the system dialog is used. Because of issue 78556 the .pdf extension will not be added automatically in this case ( .ods extension is known by the system ), thus there is a big possibility to export to the original document and to get information lost. This is a regression that was introduce by the fix for issue 68219.
BTW: looks the same for me as issue #72209
No, originally the issue 72209 was submitted regarding the case when the "Automatic file name extension" is not checked. So it describes different problem. Only the last comment describes the behavior related to this bug. The problem described here is reproducible starting from SRC680/m224, in m223 it is not reproducible. This problem is about suggested file name, that is provided in the dialog in default case ( when user does not deselect any checkbox ). And this is why it is so dangerous, it affects users who use the default settings.
excuse me, but could you explain to me how adding a new control to the IDL and activating it could possibly adversely affect other implementations (like the windows file picker) ? I do not remotely understand how this can be related to issue 68219
andreschnabel->pl: see discussion at Issue 72209 - Windows File save dialog has some strange (but according to hro - default) behavior: even if the option "automatic file name extension" is checked, it does *not* return afilename with poper extension, if the file name already contains an extension that is known to the windows system. As .odt is registered, Windows File Picker will keep this instead off adding (or replacing it by) .pdf.
Actually the fix for the issue 68219 has only triggered the problem. It has added and enabled a new control, that has triggered adding of an enable-command in the internal queue of the filepicker. The real problem was that the command queue in the filepicker implementation. Sometimes it did not allow to do correct requests in case enable-commands were in the queue. The fix is ready and will be integrated in one of cws's as soon as possible.
that makes things clearer to me, thank you.
The fix is integrated into mav24 cws.
MAV->TM: Please verify the issue.
*** Issue 81051 has been marked as a duplicate of this issue. ***
IMO, 2.3.0 must not be released with this issue unfixed, for the reasons relating to potential data loss given by the reporter. I believe this to be a showstopper, and so I ma re-opening it. IMO it should get a minimum P2 rating.
@settantta Your opinion is clear, but IMO you break the logic sequence by reopening while the issue is set to fixed and asked to be verified.
*** Issue 72209 has been marked as a duplicate of this issue. ***
@smolejv : Reading your comments on Sun Dec 3 21:13:10 +0000 2006, one could possibly understand that issue 72209 only occured when 'Automatic file extension' was not checked. (As mav pointed out). @*: - So I'm not sure if fixing this 81318 will automagically fix 72209. - Futhermore a question: does anyone know about an issue, to repair the behaviour that OOo overwrites a file that is opened at the same time (which is what happens when you export <name> to pdf as <name.odt> - and maybe also in other situations) ? Thanks, Cor
set target.
Guess what. In a hurry, just two minutes ago, file export to PDF for customer, Enter :-) Oops! Hapily thought about it just in time, to save the doc on screen again as odt. So: great and brave decision, thanks!
Checked and verified in cws mav24 -> OK !
Found fixed in 2.3.0-RC3 on WinXP-Pro
ok in OOO 2.3rc3