Issue 115214 - Export file picker does not remember last file type anymore
Summary: Export file picker does not remember last file type anymore
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO330m12
Hardware: PC All
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-10-23 09:12 UTC by hennerdrewes
Modified: 2017-05-20 10:55 UTC (History)
5 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description hennerdrewes 2010-10-23 09:12:36 UTC
In Draw, invoking "File, Export", the file picker always suggests PCT as file type. 

Expected behavior: The file picker should suggest the last used file type.

This expected behavior got fixed in issue 103568 (integrated in OOo 3.2) and has
been working fine for Draw since then, but the last used file type is not saved
in Writer.

Issue 109668 introduced a fix for writer by always suggesting a default file
type, but corrupted the behavior for Draw. With over 20 export file types
available in Draw, having the last used filter pre-selected is highly desirable.
Comment 1 hennerdrewes 2010-10-23 09:14:06 UTC
adding CCs
Comment 2 wolframgarten 2010-10-25 12:43:36 UTC
Tested this on Windows and Linux. Using File/Export in Draw I always get png as
file type , working in a saved or in a fresh file. This is visible in 3.2.1 and
in OOO330_m12.
Comment 3 hennerdrewes 2010-10-26 07:45:03 UTC
Oops, sorry, I was mistaken:

Please check it with 3.2.0. 

I have been using only the PNG export recently, so I haven't noticed the change
when I switched to 3.2.1. The regression was already introduced in that version.
Comment 4 wolframgarten 2010-10-26 14:14:12 UTC
I do not think that this issue is a showstopper. It is not a regression from the
last version (3.2.1), there is no data loss and the Office does not crash. So no
criteria fro a showstopper fits here...
Comment 5 Martin Hollmichel 2010-11-30 12:09:02 UTC
agreed, no stopper, but shouldn't we confirm this issue and fix this for the
coming release on the DEV300 code line asap ?
Comment 6 mikhail.voytenko 2010-11-30 14:29:37 UTC
The definition of the default filter is that it should be taken per default. So
in case one of the filter is default one it is a correct behavior to use it in
the dialog. If we want to change it, we should do it as a feature change.

The behavior introduced by the patch in the issue 103568 is just an
implementation detail, since it let the file-picker implementation decide which
filter should be taken. And I am in doubt that all the file-pickers remembered
the last used filter. Additionally, the behavior of any file-picker ( especially
a system file-picker ) could be changed any time.

Such implementation details are OK, but it can not be expected that they will be
a part of a feature set. If it should be a reliable feature, lets design and
implement it as such. If it should be just an implementation that probably works
somehow with some file-pickers, then it can not be really treated as a
regression, if it does not work suddenly.

I would like to set the issue to enhancement and implement the behavior for all
the file-pickers in framework in reliable way, if nobody complains.
Comment 7 Mathias_Bauer 2011-02-11 15:19:51 UTC
Comment 8 mikhail.voytenko 2011-02-18 11:26:06 UTC
Since nobody complains to my arguments, I remove the Keyword regression and set
the issue type to Enchancement.
Comment 9 Marcus 2017-05-20 10:55:32 UTC
Reset assigne to the default "".