Steps to reproduce:
1. Open the Basic IDE (Alt+F11)
2. Enter the macro below:
oFilePickerDlg = _
3. Run the macro
The file picker opens displaying the default path
The file picker opens displaying the specified path ("C:\")
Platform (if different from the browser):
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
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.
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 18.104.22.168 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit)
NEW is reserved for bugs that need a fix.
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.
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?
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.
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
I just installed LO 3.5.1.rc2 in parallel, and tested it.
The Bug is still there.
Win 7 Premium 64bit
Maybe it is helpful for the one, how is going to fix this bug, to know,
that the Windows FolderPicker-dialog works fine.
oFolderDialog = CreateUnoService("com.sun.star.ui.dialogs.FolderPicker")
If you run this macro, the Windows FolderPicker-dialog
opens in the directory C:\, as expected.
(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
Bug still exists in 22.214.171.124. 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 126.96.36.199 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.
PLs leave the version to the oldest known version with the problem.
> For more background on the problem see this old OpenOffice bug
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.
oFilePickerDlg = _
Args = _
Just for reference some other ways to initialize the dialog.
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 188.8.131.52.
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 184.108.40.206 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 220.127.116.11 works but the problem reappears in 18.104.22.168 and 22.214.171.124.
I just upgraded to 126.96.36.199 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 188.8.131.52 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 "184.108.40.206 release". After all, this is really a regression, since there was no problem with the previous version. Opinions?
I've installed version 220.127.116.11 and the bug seems to be gone again. Yay!
updated to 18.104.22.168, 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 22.214.171.124 is working for me.
I spoke too soon. I installed 126.96.36.199 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 188.8.131.52 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 184.108.40.206). 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 220.127.116.11).
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 18.104.22.168 English.
More possibly useful debugging information:
oFilePickerDlg = createUnoService("com.sun.star.ui.dialogs.FilePicker")
Args = Array(com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_SIMPLE)
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 22.214.171.124.
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:
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
It still works for me.
Version: 126.96.36.199.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
*** 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: 188.8.131.52.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
Everything works fine:
oFilePickerDlg = _
Can you please try with macro from:
' oRegistryKeyContent.WorkPathChanged = true
the problem should be reproducible.
I can't still reproduce the error with this macro :(
Sub TestSetdialog(ByVal sPath as String)
Dim dlg as Object
Dim oDoc as Object
Dim sURL as String
dlg = CreateUnoService( "com.sun.star.ui.dialogs.FilePicker" )
DialogTyp(0) = com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_AUTOEXTENSION
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)
I still repro with this:
(In reply to Niklas Johansson from comment #0)
> 2. Enter the macro below:
> Sub testFilePickerDialog
> oFilePickerDlg = _
> End Sub
With this line
(In reply to Andreas Heinisch from comment #50)
> dlg.DisplayDirectory = sPath
BASIC runtime error.
Argument is not optional
Had it as well :) Just change the path to something on your computer:
(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)