Issue 96720 - FilePicker: setDefaultName, setDefaultDirectory broken
Summary: FilePicker: setDefaultName, setDefaultDirectory broken
Alias: None
Product: App Dev
Classification: Unclassified
Component: scripting (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: PC Linux, all
: P3 Trivial
Target Milestone: 4.2.0
Assignee: AOO issues mailing list
QA Contact:
: 123544 (view as issue list)
Depends on:
Reported: 2008-11-30 08:57 UTC by probe1
Modified: 2019-10-08 12:26 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.2.0-dev
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description probe1 2008-11-30 08:57:23 UTC
Wrote a macro using FilePicker (re-using StoreDocument function from Tools
library), where the statements .setDefaultName and .setDefaultDirectory don't work.
This macro should work as a work-around for issue 22561, for Writer documents only.

Tested with OOO300m9 (OOo 3.0.0) on Linux (used vanilla RPMs).

Traced with xray in a local SUB (instead using the function), that both values
are passed correctly, but they don't show/take effect on .execute the dialogue.

Relevant part of macro is this:
' ---------------------------------
Sub test_FileSave
   ' load helper function library
   If NOT GlobalScope.BasicLibraries.isLibraryLoaded( "Tools" ) Then
      GlobalScope.BasicLibraries.loadLibrary( "Tools" ) 
   End If

   ' create a list of available FilterNames
   ' use procedure from TOOLS library
   StoreDocument( ThisComponent, aFilterNames, "FilenameProposal", "/home" )
End If

' ---------------------------------
' add FilterNames
Sub addWriterFilterNames
oMasterKey = GetRegistryKeyContent("org.openoffice.TypeDetection.Types")
oTypes() = oMasterKey.Types
oUIKey =

aFilterNames(0,0) = oTypes.GetByName("writer8").UIName & " (*.odt)"
aFilterNames(0,1) = "*.odt"
aFilterNames(0,2) = oTypes.GetByName("writer8").Name

aFilterNames(1,0) = oTypes.GetByName("writer8_template").UIName & " (*.ott)"
aFilterNames(1,1) = "*.ott"
aFilterNames(1,2) = oTypes.GetByName("writer8_template").Name

End Sub
' ---------------------------------
Comment 1 kay.ramme 2008-12-01 09:25:56 UTC
Andreas, is that yours ... or should it go to Hennes?
Comment 2 probe1 2008-12-01 16:40:36 UTC
Sorry, have forgotten the definition above posted code:

Private aFilterNames(1,2) as String
Comment 3 probe1 2008-12-01 16:40:49 UTC
Sorry, have forgotten the definition above posted code:

Private aFilterNames(1,2) as String

Comment 4 ab 2008-12-02 08:01:47 UTC
ab->hro: In dev300 m35 it works on Windows but I could reproduce the
problem on Linux. From Basic's view these are just generic calls to
setDisplayDirectory() and setDisplayName() at the FilePicker service
and I doubt that this fails on Linux only. Please have a look.
Comment 5 kai.sommerfeld 2009-06-16 09:55:21 UTC
pl: Something for you?
Comment 6 philipp.lohmann 2009-06-23 11:19:02 UTC
pl->cd: I think file pickers are your domain these days ?
Comment 7 carsten.driesner 2009-06-23 12:55:07 UTC
cd: I will check this. Added to CWS filepicker01.
Comment 8 carsten.driesner 2009-09-14 11:17:14 UTC
cd: I have too much issues to fix all of them for OOo 3.2.  Due to missing time
this issue must be moved to the next release OOo 3.3.
Comment 9 paule100 2010-03-12 17:35:28 UTC
This issue seems to affect different filePicker templates differently. I test
the following two under Ubuntu (OO 3.1) and WindowsXP (OO 3.2)

Under WindowsXP both methods work with both templates.

Under Ubuntu ONLY setDefaultName() does not work with FILEOPEN_SIMPLE, the other
3 combinations work!

By the way the Sub StoreDocument (which appeares at the initial comment of this
issue) uses the template

But I did not test this one.
Comment 10 carsten.driesner 2010-08-06 15:03:07 UTC
cd: Too late to fixed for OOo 3.3. Must be shifted to next release.
Comment 11 damjan 2015-11-25 17:20:33 UTC
There is many issues here.

1. "Under Ubuntu ONLY setDefaultName() does not work with FILEOPEN_SIMPLE".

Yes, this is **by design**. GTK can't support gtk_file_chooser_default_set_current_name() for opening files, it gives the following assertion:

(soffice:81466): Gtk-CRITICAL **: gtk_file_chooser_default_set_current_name: assertion 'impl->action == GTK_FILE_CHOOSER_ACTION_SAVE || impl->action == GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER' failed

which is why AOO doesn't even try to call gtk_file_chooser_default_set_current_name() when the OPEN dialog is shown (see SalGtkFilePicker::setDefaultName). The suggested filename can only be used when saving. Blame GTK.

2. The code from the OP is just plain wrong: the current directory needs to be given as a URL. The documentation for XFilePicker requires a URL for setDisplayDirectory(). "/home" is not a URL. It should be "file:///home"

3. allows paths instead of URLs (both C:/ and file:///C:/ work, file:/C:/ doesn't), but other platforms are stricter!!!

4. For, when the directory isn't a URL, the default filename isn't shown either. I feel that when the directory is wrong it shouldn't affect the file; not only is there no good reason for it to, but it can also confuse users as to what is wrong, like the OP here who believed both the file and directory are broken.
Comment 12 Regina Henschel 2015-11-25 18:19:06 UTC
@damjan: One error is a wrong property in VistaFilePicker.cxx, see my fix in

When you (or someone else) work on the problem, please fix that too. I'm currently to busy to fix it myself.
Comment 13 damjan 2015-11-25 18:50:54 UTC
Committed r1716508 fixing point 4:

Display the proposed filename even when the URL
specified for the file picker directory is invalid.

As the Win32 file picker sadly allows both paths and URLs
for directories, users try paths on other more
restrictive platforms, and since the file picker there
shows neither the directory nor the file, they wrongly
conclude both are broken.
Comment 14 oooforum (fr) 2017-05-31 14:56:01 UTC
Thanks Damjan for the fix.
This issue is targeted for 4.2.0
I don't know if this commit can be backported for 4.1.4?
Comment 15 oooforum (fr) 2019-10-08 12:26:19 UTC
*** Issue 123544 has been marked as a duplicate of this issue. ***