Bug Hunting Session
Bug 43021 - Macros: FilePicker method setDisplayDirectory shows wrong folder with native dialog Win 7 (64-bit)
Summary: Macros: FilePicker method setDisplayDirectory shows wrong folder with native ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 67351 70843 95722 (view as bug list)
Depends on:
Blocks: Macro-Windows
  Show dependency treegraph
 
Reported: 2011-11-17 03:31 UTC by Niklas Johansson
Modified: 2019-10-19 12:33 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
A macro workaround for setDisplayDirectory (19.50 KB, application/vnd.oasis.opendocument.text)
2015-09-05 16:36 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Niklas Johansson 2011-11-17 03:31:31 UTC
Problem description: 

Steps to reproduce:
1. Open the Basic IDE (Alt+F11)

2. Enter the macro below:
Sub testFilePickerDialog
    oFilePickerDlg = _
        createUnoService("com.sun.star.ui.dialogs.FilePicker")
    oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\"))
    oFilePickerDlg.execute()
End Sub

3. Run the macro

Current behavior:
The file picker opens displaying the default path

Expected behavior:
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
Comment 1 Frieder 2011-11-21 03:14:40 UTC
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"
Comment 2 Frieder 2011-11-21 03:21:16 UTC Comment hidden (obsolete)
Comment 3 Rainer Bielefeld Retired 2012-03-10 02:09:15 UTC
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>
Comment 4 Frieder 2012-03-10 06:14:30 UTC
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
Comment 5 Rainer Bielefeld Retired 2012-03-10 07:23:22 UTC
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
Comment 6 Frieder 2012-03-10 07:28:03 UTC
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
Comment 7 Frieder 2012-03-10 07:54:50 UTC
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 )
Comment 8 Rainer Bielefeld Retired 2012-05-24 09:22:41 UTC
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.
Comment 9 Mark Nienberg 2012-07-18 23:04:51 UTC
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
Comment 10 Marc Sabatella 2012-08-10 16:26:11 UTC
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).
Comment 11 Pascal Becker 2013-04-18 08:25:09 UTC
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.
Comment 12 Cor Nouws 2013-04-18 20:58:00 UTC
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
Comment 13 Niklas Johansson 2013-06-18 13:44:26 UTC
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
Comment 14 Mark Nienberg 2013-06-19 21:03:27 UTC
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.
Comment 15 Niklas Johansson 2013-07-29 14:00:53 UTC
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.
Comment 16 Mark Nienberg 2013-07-29 16:22:33 UTC
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.
Comment 17 Jesus Corrius 2013-07-29 16:28:38 UTC
Assign it to me
Comment 18 Cor Nouws 2013-07-29 22:11:57 UTC
*** Bug 67351 has been marked as a duplicate of this bug. ***
Comment 19 Mark Nienberg 2013-10-11 18:12:23 UTC
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.
Comment 20 Mark Nienberg 2013-11-04 23:04:42 UTC
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.
Comment 21 wuxxin 2014-02-10 14:38:10 UTC
libreoffice 4.2.0.4 64bit, windows 7 german: The problem is here again, the described workaround in comment 13 does NOT work.
Comment 22 Mark Nienberg 2014-02-10 17:46:19 UTC
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?
Comment 23 Mark Nienberg 2014-02-26 17:34:45 UTC
I've installed version 4.2.1.1 and the bug seems to be gone again. Yay!
Comment 24 wuxxin 2014-02-27 20:15:44 UTC
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.
Comment 25 Mark Nienberg 2014-04-16 17:35:03 UTC
English version of 4.2.3.3 is working for me.
Comment 26 Mark Nienberg 2014-04-23 16:57:27 UTC
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.
Comment 27 wuxxin 2014-04-24 13:37:40 UTC
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.
Comment 28 Mark Nienberg 2014-04-25 19:05:42 UTC
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.
Comment 29 Ewald Anderl 2014-04-29 04:28:05 UTC
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.
Comment 30 Ewald Anderl 2014-05-02 23:06:08 UTC
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.
Comment 31 Ewald Anderl 2014-05-06 13:06:09 UTC
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.
Comment 32 Mark Nienberg 2014-06-04 21:52:26 UTC
Just confirming that the bug still exists in LO 4.2.4.2 English.
Comment 33 Mark Nienberg 2014-06-05 00:42:45 UTC
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.
Comment 34 Mark Nienberg 2014-07-14 17:11:36 UTC
Just confirming the bug still exists in 4.2.5.2.
Comment 35 wuxxin 2014-07-22 16:15:59 UTC
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)
Comment 36 Regina Henschel 2015-08-31 16:59:31 UTC
(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.
Comment 37 Oliver Brinzing 2015-09-02 06:38:43 UTC Comment hidden (no-value)
Comment 38 Regina Henschel 2015-09-05 16:36:55 UTC
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.
Comment 39 Mark Nienberg 2015-09-11 18:36:56 UTC
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?
Comment 40 Regina Henschel 2015-09-11 21:00:17 UTC
No, the needed corrected getDisplayDirectory will be available in 5.0.3, not in 5.0.2.
Comment 41 Niklas Johansson 2015-09-13 20:25:37 UTC
(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.
Comment 42 Mark Nienberg 2015-10-05 17:27:04 UTC
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.
Comment 43 Xisco Faulí 2017-07-13 10:03:08 UTC
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Comment 44 Sherilyn 2018-06-25 01:45:31 UTC Comment hidden (spam)
Comment 45 Buovjaga 2019-08-11 10:05:48 UTC
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
Comment 46 Buovjaga 2019-08-11 11:14:15 UTC
*** Bug 70843 has been marked as a duplicate of this bug. ***
Comment 47 Buovjaga 2019-08-11 11:14:43 UTC
*** Bug 95722 has been marked as a duplicate of this bug. ***
Comment 48 Andreas Heinisch 2019-08-27 08:18:55 UTC
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
Comment 49 Oliver Brinzing 2019-08-27 12:32:02 UTC
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.
Comment 50 Andreas Heinisch 2019-08-29 07:15:36 UTC
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
Comment 51 Buovjaga 2019-08-29 07:31:00 UTC
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
Comment 52 Andreas Heinisch 2019-08-29 09:06:56 UTC
Had it as well :) Just change the path to something on your computer:

Call TestSetdialog("C:/AMD")
Call TestSetdialog("C:/Logs")
Comment 53 Buovjaga 2019-08-29 10:02:10 UTC
(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)