Bug 43021

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"

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)