Hello 
I Can confirm that behaviour.
But this Bug seems to bee older.
I'm using LO 3.3.4 (German ) and Windows7 64 bit
On my Linux - System Te Problem doesn't exist.
But I remember , that this Problem also appeared in earlier Versions.
I know for sure that it also appeared in Version 3.3.3 .
but I don't know  in which version it appeared first.

Workaround:
Use the FilePickerDialog from Libreoffice instead of the one from Windows.
Menu: Tools-> Options-> LibreOffice->General->Select "Use LibreOffice diaogs"

NOT reproducible with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit),

NOT reproducible with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) 

@Frieder:
NEW is reserved for bugs that need a fix.
<https://wiki.documentfoundation.org/QA-FAQ#How_to_select_correct_Bug_Status>

Hello


I tested it with Lo 3.4.5 portable(German), and LO 3.5.0 RC2 (on win7 premium 64bit German)
and with both versions the bug is still there.

The FilePicker is one of the most used functions in Macros, Extensions, and Templates.
and therefore this bug should be fixed soon. 

@Rainer Bielefeld:
It was and is absolutely correct, that I selected "New" for the Status,
because this Bug needed to be fixed at the time I wrote the report,
and it still needs to be fixed.
But you are wrong, putting the State to "resolved".
Up to now nobody fixed  this bug, so  I really doubt, that you tested it correctly.
Are you sure, that you used the Windows-dialogs, and not the  LibreOffice-diaogs?

regards Frieder

Strange, I can't reproduce my successful test I did in the morning. Now it's reproducible with all LibO Versions I tested on WIN7 64 bit (including Master 3.6). May be my lots of tests with various versions, profiles, ... die some faith healing :-/

Seems inherited from OOo, because OOo 3.3 and OOo 3.4 show the same problem. 

Works fine with OOo 3.1.1

Works fine With LibO 3.5 IWN XP 32bit on VirtualBox

Something strange I remember from my tests in the morning is that I saw "C:\" in the file dialog Path pane instead the normal "> Computer > Local HD (C:) > ", what ever that might explain.

Using URL syntax "file:///C:/" will work, but not heal the problem with the WIN dialog.

@Noel:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug

Hello

Addition:
I just installed LO 3.5.1.rc2 in parallel, and tested it.
Result:
The Bug is still there. 

My System:
Win 7 Premium 64bit

Hello

Addition2:
Maybe it is helpful for the one, how is going to fix this bug, to know,
that the Windows FolderPicker-dialog works  fine.


Sub testFolderPickerDialog
  oFolderDialog = CreateUnoService("com.sun.star.ui.dialogs.FolderPicker")
  oFolderDialog.SetDisplayDirectory(ConvertToURL("C:\"))
  oFolderDialog.Execute
End Sub

If you run this macro, the Windows FolderPicker-dialog
opens in the directory C:\, as expected.

regards Frieder
(LO3.5.1.rc2 on Win7 )

Now works for me with parallel installation of Master "LOdev 3.6.0alpha0+   WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 5b81e2d]" (tinderbox: W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-05-23 22:18:38)

Please fell free to reopen if you see the problem reappearing.

This problem still exists for me using 3.5.4 on Windows 7 64-bit. Dialogs work as expected when using LibreOffice dialogs but do not work when using system dialogs.

For more background on the problem see this old OpenOffice bug
https://issues.apache.org/ooo/show_bug.cgi?id=110141

Bug still exists in 3.6.0.4.  setDisplayDirectory is completely ignored on my Windows 7 system.

Noteworthy side effect of this: passing in "" as the argument produces no error on Windows but does on Linux (a warning dialog appears when the filepicker is executed).

Just tested it with Version 4.0.2.2 on a Windows 7 x64 Prof. System.
It also displays the wrong directory, no matter if i'm using drive names like "C:\" or UNC-Paths like "\\Servername\somedir\".

Along i tried to get the actual directory from the filepicker with oFilePickerDlg.getDisplayDirectory() and getting an empty string back.

Hey guys,

PLs leave the version to the oldest known version with the problem.

This:
> For more background on the problem see this old OpenOffice bug
> https://issues.apache.org/ooo/show_bug.cgi?id=110141
shows it's an old bug from OOo

Found a workaround, still think that it would be nice if it worked without the extra code just as it does on other platforms.

If we explicitly initialize the dialog then we are able to use setDisplayDirectory. 

Sub testFilePickerDialog
    oFilePickerDlg = _
        createUnoService("com.sun.star.ui.dialogs.FilePicker")
    Args = _
        Array(com.sun.star.ui.dialogs.TemplateDescription.FILEOPEN_SIMPLE)
    oFilePickerDlg.initialize(Args)
    oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\"))
    oFilePickerDlg.execute()
End Sub

Just for reference some other ways to initialize the dialog.
http://api.libreoffice.org/docs/common/ref/com/sun/star/ui/dialogs/TemplateDescription.html

I'm a bit confused now. I have been using code similar to Comment #13 for some time now and it did not work on Windows 7, so I switched to using the LibreOffice dialogs (which my users didn't like very much). Now that I see Comment #13 I tested my code with Windows System dialogs and it works! So I'm guessing something was fixed in a prior release of LibreOffice or in a Windows 7 update. Anyway, my users will be happy about this. We are still on 4.0.1.2.

So I'm confused now too. The code that I posted in June does not work anymore. This time I tried it in LibreOffice 4.0.4. 

There might very well be some change in Windows that triggered the problem to reappear. Does anybody else have an older version installed like 4.0.3 and a 64-bit version of Windows 7? I think that I used 4.0.4 when testing my code the last time.

It still works for me with Libre 4.0.1.2 and Windows 7 x64. Windows is fully up-to-date. So if it isn't working for you in Libre 4.0.4 then it seems like a Libre problem rather than a Windows problem. That would be disappointing and would prevent me from upgrading my 28 users.

Assign it to me

*** Bug 67351 has been marked as a duplicate of this bug. ***

The comments in Bug 67351 should be useful in further narrowing down the problem. It says that the 4.0.3.3 works but the problem reappears in 4.0.4.2 and 4.1.0.4.

I just upgraded to 4.1.3.2 and the problem is gone again. I guess I would consider marking this closed, except that I'm not sure anyone understands why it keeps reappearing in subsequent releases.

libreoffice 4.2.0.4 64bit, windows 7 german: The problem is here again, the described workaround in comment 13 does NOT work.

That's really disappointing. There is another fix in 4.2 that my 30 users are waiting for, but this is more important for us. I'm wondering if we could get more attention by changing the Version from "Inherited From OOo" to "4.2.0.4 release". After all, this is really a regression, since there was no problem with the previous version. Opinions?

I've installed version 4.2.1.1 and the bug seems to be gone again. Yay!

updated to 4.2.1.1, win 7 same setup as in comment 21:
tried out samples description and from comment 13:

with internal file dialog everything works as expected,

with windows file dialog the directory T:\TEXTE (one of the used standard directories of the user) is always opened.

I searched for T:\Texte in registrymodifications.xcu but beside history entries nothing was found.

where could the strange "T:\Texte" default come from ?
The behaviour is consistent over the 7 machines deployed here.

Only one machine is used to make manual changes, every other machine is getting an automated setup.

English version of 4.2.3.3 is working for me.

I spoke too soon. I installed 4.2.3.3 on a test machine and it is working fine, but then I installed on two more office machines and the FilePicker bug is back on those machines. Currently scratching our heads to try to find any difference between the two installs that would account for this.

Any troubleshooting suggestions welcome.

i did not try 4.2.3.3 so far, but the behaviour is similar. It worked in the beginning, but stopped soon after. I also have no idea what changed in between.

I succeeded in breaking the installation that was working simply by using the Windows System SaveAs dialog to save a file. Now the FilePicker ignores my specified directory and defaults to the directory where I last saved a file (using the system SaveAs). 

I thought I might be able to clear this value before I call FilePicker, but I haven't been able to figure out where windows is saving it.

I can confirm that I have observed this problem as well (Windows 7, 64bit, LibreOffice 4.2.3.3). The LibreOffice dialog works, all attempts to call setDisplayDirectory() have no effect. Any calls to getDisplayDirectory() return an empty string (""). The get/setDisplayDirectory() works fine when the LibreOffice dialog style is slected. Both system/LibreOffice dialog(s) work for valid paths on Linux (fc20, also LO 4.2.3.3).

After running numerous test cases, it appears that for my installation the directory that is shown was a FilePicker selection made in some prior call to execute the dialog. This can be reproduced by running a simple test/demo program that selects a file (you don't need to actually do anything with the file), and from them on that is the initial directory displayed.

I can also verify that getDisplayDirectory() continues to return "".

I was going to report this as a bug, but noticed that this bug was already opened. Let me know if you need more info and/or screen shots.

FYI, I may have uncovered a related problem. There appears to be a race condition where getDisplayDirectory incorrectly returns an empty string. See bug 78209 for more information.

I can confirm that FolderPicker, while mirroring FilePicker behavior in almost all respects, does NOT reproduce Bugzilla 43021 behavior. Hope this helps in tracking down the problem.

Confirmed by swapping FolderPicker for FilePicker when creating dialog object and comparing "working" vs. "non-working".

Screen shots and code used to reproduce problems uploaded supporting Bugzilla 78210 and 78315.

Just confirming that the bug still exists in LO 4.2.4.2 English.

More possibly useful debugging information:

Sub testFilePickerAgain
    oFilePickerDlg = createUnoService("com.sun.star.ui.dialogs.FilePicker")
    Args = Array(com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_SIMPLE)
    oFilePickerDlg.initialize(Args)
    oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\"))
    oFilePickerDlg.execute()
End Sub


If I change FILESAVE_SIMPLE to FILESAVE_AUTOEXTENSION the dialog box opens in a different (but still wrong) directory. Changing back to SIMPLE changes the opening directory back to the previous (but still wrong) directory.

Just confirming the bug still exists in 4.2.5.2.

as additional information, using the internal libreoffice filepicker is a suboptimal workaround, because it consumes lot of cpu cycles every time a directory gets opened if there are more than 50 to 100 documents inside this directory. (as in 2 to 3 seconds for save or open)

My workaround is to move old documents out of the way in a archive directory (which would be done anyways, but only after the document was not modified within 3 months, which is currently to much to use the internal filepicker without interrupting the workflow of the user (eg. 2 seconds or more on save, open, a.s.o)

(In reply to Ewald Anderl from comment #29)
> Any calls to getDisplayDirectory()
> return an empty string (""). 

That is a different problem. I have put it into bug #93634, and I have a fix for that.

Created attachment 118439 [details]
A macro workaround for setDisplayDirectory

I have attached a document, which contains a macro with a workaround I have got from https://bz.apache.org/ooo/show_bug.cgi?id=123544#c25. If you want to test it, you need a current daily build, which contains already the fix of bug #93634.

It is not a total solution but a workaround. The directory, which the user has used for opening, is not written back to the file picker object in Basic. I have initialized the file picker object again and then the updated DisplayDirectory is available. I suspect, that it is not a problem in the code of the file picker, because that works in normal situations. But I think it might be a problem in the way Basic uses these objects.

Great to see renewed interest and some progress on this longstanding bug. Rather than messing with the daily build, can I just wait for 5.0.2 and then test the workaround?

No, the needed corrected getDisplayDirectory will be available in 5.0.3, not in 5.0.2.

(In reply to Mark Nienberg from comment #39)
> Great to see renewed interest and some progress on this longstanding bug.
> Rather than messing with the daily build, can I just wait for 5.0.2 and then
> test the workaround?

Just to clarify, you can still use the workaround in current versions of LibreOffice and the correct display directory will be shown. It is the fix for getDisplayDirectory that you need to wait for.

Thanks a lot Regina and Oliver

Worth noting is Ariel's comment that one can use the service:

"com.sun.star.ui.dialogs.OfficeFilePicker"

instead of 

"com.sun.star.ui.dialogs.FilePicker"

and thereby use LibreOffice own dialogs without changing the default setting for other scenarios opening files etc.

Confirmed that the workaround solves the display directory problem for me using 5.0.2. My code isn't using getDisplayDirectory so I am finally able to revert to the System dialogs. My users will be happy with this!

Thanks to all who have been and still are working on this issue.

Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue

Still repro

Version: 6.4.0.0.alpha0+ (x86)
Build ID: c738be4de6886a0c96b7d10df7e78c8b2964c135
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI-Language: en-US
Calc: threaded

*** Bug 70843 has been marked as a duplicate of this bug. ***

*** Bug 95722 has been marked as a duplicate of this bug. ***

Unfortunately I can not reproduce the error with:

Version: 6.4.0.0.alpha0+ (x86)
Build ID: 07f9223daae92ac11be2382ecd0095e744f5695f
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: CL

Everything works fine:
Sub testFilePickerDialog
    oFilePickerDlg = _
        createUnoService("com.sun.star.ui.dialogs.FilePicker")
    oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\AMD\"))
    oFilePickerDlg.execute()
End Sub

Can you please try with macro from:
https://bz.apache.org/ooo/show_bug.cgi?id=123544#c25

with disabled:
'    oRegistryKeyContent.WorkPathChanged = true
'    oRegistryKeyContent.commitChanges
the problem should be reproducible.

I can't still reproduce the error with this macro :(

OPTION EXPLICIT

Sub Main()
	Call TestSetdialog("C:/AMD")
	Call TestSetdialog("C:/Logs")
End Sub

Sub TestSetdialog(ByVal sPath as String)
	Dim dlg as Object
	Dim oDoc as Object
	Dim mNoArgs()
	Dim sURL as String

	dlg = CreateUnoService( "com.sun.star.ui.dialogs.FilePicker" )
	
	Dim Dialogtyp(0)
	DialogTyp(0) = com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_AUTOEXTENSION

	dlg.initialize(DialogTyp())
	dlg.Title = "Test"

	sURL = "private:factory/swriter"
	oDoc = StarDesktop.loadComponentFromURL(sURL, "_blank", 0, mNoArgs)

    Dim oConfigProvider as Object
    Dim oRegistryKeyContent as Object
    Dim aNodePath(0) as new com.sun.star.beans.PropertyValue
    oConfigProvider = createUnoService("com.sun.star.configuration.ConfigurationProvider")
    aNodePath(0).Name = "nodepath"
    aNodePath(0).Value = "/org.openoffice.Office.Common/Path/Info"
    oRegistryKeyContent = oConfigProvider.createInstanceWithArguments("com.sun.star.configuration.ConfigurationUpdateAccess", aNodePath())

    dlg.DisplayDirectory = sPath

	If dlg.Execute = 1 Then 
		sURL = dlg.Files(0)
		oDoc.storeAsURL(sURL, mNoArgs)
	EndIf

End Sub

I still repro with this:
(In reply to Niklas Johansson from comment #0)
> 2. Enter the macro below:
> Sub testFilePickerDialog
>     oFilePickerDlg = _
>         createUnoService("com.sun.star.ui.dialogs.FilePicker")
>     oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\"))
>     oFilePickerDlg.execute()
> End Sub

With this line

(In reply to Andreas Heinisch from comment #50)
>     dlg.DisplayDirectory = sPath

I get:
BASIC runtime error.
Argument is not optional

Had it as well :) Just change the path to something on your computer:

Call TestSetdialog("C:/AMD")
Call TestSetdialog("C:/Logs")

(In reply to Andreas Heinisch from comment #52)
> Had it as well :) Just change the path to something on your computer:
> 
> Call TestSetdialog("C:/AMD")
> Call TestSetdialog("C:/Logs")

I forgot to mention these folders existed (I created AMD to match)

The problem is the usage of SetDefaultFolder to set the directory of the file picker in setDisplayDirectory. From MS docs: "Sets the folder used as a default if there is not a recently used folder value available."

So now there is: https://gerrit.libreoffice.org/#/c/83409/

This basically opts-out of the recent folder OS level management and just relies on the LO's internal storage of the last folder from open and save dialogs, like all other backends do. The Vista file picker code already uses FOS_DONTADDTORECENT, so I don't understand, which this interferes at all, but maybe that just doesn't add but (as seen in this bug) obviously still uses the list. And if we don't add, I don't see the point to rely on it at all.

An other idea was to modify the recently used list with the new folder. But the only API I could find was StorageItemMostRecentlyUsedList, which looks like it's only available in Windows 10 and I'm not sure this would be the better result.

I also looked at Regina's workaround. Eventually the new picker somehow resets the COM environment, but I didn't dig deeper into it, as for me it even wrong on the first start of the macro.

Created attachment 156005 [details]
Easier test document with a button to open the file picker

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ffa636ba74b04b3258ec9a696bc4eac33581fa24

tdf#43021 WIN opt-out of OS recent folder usage

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

This is fixed now fixed. There is an other bug, which prevents LO to accept single-backslash file URI, which might be related, if you construct URIs yourself: https://gerrit.libreoffice.org/#/c/83837/

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/a20e061d0a54e027a9cf3702fdc88b94e9ec8c18

tdf#43021 WIN opt-out of OS recent folder usage

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Commit Notification from comment #58)
 
> Affected users are encouraged to test the fix and report feedback.
@Jan -- was the intention to patch Macro behavior alone, or was it also intended to change the behavior of LO in general?  

In 6.3.4.2, in general LO follows the principle quoted in comment #54
From MS docs: "Sets the folder used as a default if there is not a recently used folder value available."

But since 6.4.0.1, LO always uses the "default" folder, and not the "last used directory"  (see bug #129886). My belief is that LO should continue to use "last used directory" (and default to the path set in Options if "last used" is not available). (see bug #129292, comment 2)

Thanks for clarification.

(In reply to sdc.blanco from comment #59)
> (In reply to Commit Notification from comment #58)
>  
> > Affected users are encouraged to test the fix and report feedback.
> @Jan -- was the intention to patch Macro behavior alone, or was it also
> intended to change the behavior of LO in general?  
> 
> In 6.3.4.2, in general LO follows the principle quoted in comment #54
> From MS docs: "Sets the folder used as a default if there is not a recently
> used folder value available."
> 
> But since 6.4.0.1, LO always uses the "default" folder, and not the "last
> used directory"  (see bug #129886). My belief is that LO should continue to
> use "last used directory" (and default to the path set in Options if "last
> used" is not available). (see bug #129292, comment 2)
> 
> Thanks for clarification.

Adding Jan-Marek to Cc.

LOs file picker API just has setDisplayDirectory to set a directory for the file picker. Windows has two functions to set the folder:SetDefaultFolder and SetFolder. The Microsoft documentation for SetFolder explicitly mentions: "In general, we do not recommended the use of this method. [...] SetDefaultFolder is the better method." So much for MS POV.

The merged patch boils down to changing SetDefaultFolder to SetFolder in the Windows implementation of LOs file picker service. This will always set the folder and not just the first time, because that is the behavior a caller of LOs API expects.

Now LO got some bug reports due to this fundamental change, that basically makes folder handling common on all platforms and relies on LO internal handling of the last folder selection.

From bug 130535 I can see, that Windows even manages to keep two distinguish folders for the PDF export and normally saved documents. AFAIK that is nothing that LO did on purpose.

And there is nothing like a BASIC API, as the file picker is a service inside LO and BASIC simply calls all services by some kind of reflection API / UNO. And at this point there is no way for the file picker to distinguish these calls. And just to make this clear: this is not a BASIC problem. This happens with all UNO bindings, which also includes LO internal file picker usage. My problem was actually a customer error report for a Java extension.

Then there is bug 129292 about the default folder handling in general.

But I'm / LO is open for ideas / enhancements, which should be handled in a new report. Maybe there should be an option to explicitly switch between LOs default and Windows preferred behavior. Or an additional API, like the SetDefaultFolder. But I don't know if any other OS even has some equivalent of that API.

From my POV this fix is correct. If you set an explicit folder via the API, you expect it to be set in the file picker you open.

For the record, the following patch adds internal tracking of the last used directory, thus restoring the functionality that went missing with this bugfix.

(See bug 126665)

https://git.libreoffice.org/core/commit/d157c1bd70d630a58db33910d550bb8dee9fe62e