1. New Document. 2. Save (but not in the Directory named in Options>LibreOffice>Paths>MyDocuments) 3. Second New Document. 4. Save. Actual Result: opens directory specified in Paths-My Documents Expected Result: opens directory where first document was saved. Actual result obtained in: Version: 6.5.0.0.alpha0+ (x64) Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: threaded (7 jan 2020 build) Expected result obtained in: Version: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: de-DE (en_DK); UI-Language: en-US Calc: threaded Uncertain if this change was intentional. Cf bug #96503 and bug #129292
also reproducible with Version: 6.4.0.1 (x64) Build-ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc saving a new document always preselects workdir.
I see this as a duplicate of #129292, just with opposite request. Please close and write there.
(In reply to Timur from comment #2) > I see this as a duplicate of #129292, just with opposite request. > Please close and write there. This report (bug 129886) is to note a bug in the intended action. It appears in 6.4.0.1rc and forward (but not in 6.3.x). In effect, a regression. (Bug 129291 was classified as a "documentation" problem, not an enhancement.)
(In reply to Oliver Brinzing from comment #1) > also reproducible with > > Version: 6.4.0.1 (x64) Does it work (as expected) for you with 6.3.x? Maybe we should mark this as possibleRegression and bibisectrequest?
(In reply to sdc.blanco from comment #4) > Does it work (as expected) for you with 6.3.x? Maybe we should mark this as > possibleRegression and bibisectrequest? The new behaviour was intended, please have a look at: Bug 43021 - Macros: FilePicker method setDisplayDirectory shows wrong folder with native dialog Win 7 (64-bit) Until LO 6.3.4 it was necessary to use a workaround via "WorkPathChanged" to force the windows filepickter to show a directory, e.g.: https://bugs.documentfoundation.org/show_bug.cgi?id=43021#c50 [...] oRegistryKeyContent.WorkPathChanged = true oRegistryKeyContent.commitChanges [...] oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\test\"))
(In reply to Oliver Brinzing from comment #5) > The new behaviour was intended, please have a look at: I am still uncertain. > Bug 43021 - Macros: FilePicker method setDisplayDirectory shows wrong folder > with native dialog Win 7 (64-bit) Good detective work on your part, but isn't that bug supposed to be about Macros (and how the Basic commands work)? (that is how it is classified). Meanwhile, I can understand that this is where/how the new behavior was introduced, but maybe it was an "accident" in the sense that the repair of the macros has also spilled over into the "standard" behavior?
(In reply to sdc.blanco from comment #6) > Good detective work on your part, but isn't that bug supposed to be about > Macros (and how the Basic commands work)? (that is how it is classified). > > Meanwhile, I can understand that this is where/how the new behavior was > introduced, but maybe it was an "accident" in the sense that the repair of > the macros has also spilled over into the "standard" behavior? While bug 43021 was about macros, related bug 34303 wasn't; and in fact, the change has the intended result that management of initial directories in File dialogs has been made consistent over platforms and managed by LibreOffice (while previously, it was managed by system on Windows). So any "regression" aspect of this report should be removed, and if some change in behaviour is wanted, it should be suggested, discussed and implemented as a general change, unrelated to previous state. It should take different kind of dialogs (open/save/export/direct export/macro; different modules) into account; if, why and how should they behave differently on different OSes, etc.
ok, so fixing a bug in macros that affects maybe 3% of the users breaks the workflow for all LibO windows users ... I doubt that this is well balanced ;) Regarding the "regression" vs. "enhancement" topic: from a user perspective, its definitely a regression, because it simply worked up until 6.3 and doesn't work anymore in 6.4. It doesn't matter if the old behavior was "unintentional", it was the old behavior and it had its advantages. To make it short: I also would love to have an option to choose between "Use last saved Dir" and "use default-dir". I think this can be achieved without breaking the macros again, even thou it is really an enhancement then, that requiriere some new code. Maybe we can undo the commit that fixes the macro-bug until this new code is available? I doubt that this new function will be introduced in a feature-frozen 6.4 series...
*** Bug 133674 has been marked as a duplicate of this bug. ***
Bug/Regression still exists in 7.0 Beta 2...
*** This bug has been marked as a duplicate of bug 126665 ***