Apache OpenOffice (AOO) Bugzilla – Issue 96720
FilePicker: setDefaultName, setDefaultDirectory broken
Last modified: 2019-10-08 12:26:19 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 addWriterFilterNames() ' 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 = GetRegistryKeyContent("org.openoffice.Office.UI/FilterClassification/LocalFilters") 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 ' ---------------------------------
Andreas, is that yours ... or should it go to Hennes?
Sorry, have forgotten the definition above posted code: Private aFilterNames(1,2) as String
Sorry, have forgotten the definition above posted code: Private aFilterNames(1,2) as String Cheers Winfried
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.
pl: Something for you?
pl->cd: I think file pickers are your domain these days ?
cd: I will check this. Added to CWS filepicker01.
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.
This issue seems to affect different filePicker templates differently. I test the following two under Ubuntu (OO 3.1) and WindowsXP (OO 3.2) com.sun.star.ui.dialogs.TemplateDescription.FILEOPEN_SIMPLE com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_SIMPLE 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 com.sun.star.ui.dialogs.TemplateDescription.FILESAVE_AUTOEXTENSION_PASSWORD But I did not test this one.
cd: Too late to fixed for OOo 3.3. Must be shifted to next release.
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. com.sun.star.ui.dialogs.Win32FilePicker allows paths instead of URLs (both C:/ and file:///C:/ work, file:/C:/ doesn't), but other platforms are stricter!!! 4. For com.sun.star.ui.dialogs.FilePicker, 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.
@damjan: One error is a wrong property in VistaFilePicker.cxx, see my fix in http://cgit.freedesktop.org/libreoffice/core/commit/?id=8775593bcc543b3d7021e20736f42fa13035870d When you (or someone else) work on the problem, please fix that too. I'm currently to busy to fix it myself.
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.
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?
*** Issue 123544 has been marked as a duplicate of this issue. ***