Apache OpenOffice (AOO) Bugzilla – Issue 90219
Opening native file picker from Basic Makro (com.sun.star.ui.dialogs.FilePicker) does nothing
Last modified: 2012-05-28 11:26:27 UTC
...not even trows an exception. Try using template changer extension on http://extensions.services.openoffice.org/project/templatechanger. It adds a new menu entry in Files - Templates calles "Assign new" which basically opens a file picker to assign a new template to the documnet. On Mac OS X aqua nothing happens. Choosing Tools - Options - General "Use OOo-Dialogs" brings everything to work as expected. Code from Main is: 'Error handling for broken KDE-Filepicker implementation On Error Goto OpenOOoFilePicker ' try to create the default FilePicker oFp = createunoservice("com.sun.star.ui.dialogs.FilePicker") Goto CreatedFilePicker ' if we get an error - tryto open the OOo filepicker OpenOOoFilePicker: On Error Goto 0 bUseSystemFilePicker = ChangeSystemFileDialog (false) oFp = createunoservice("com.sun.star.ui.dialogs.FilePicker") ChangeSystemFileDialog (bUseSystemFilePicker) this should swich to OOos File picker if no native File picker works. But neither an exception nor an error message occurs there.
Indeed : nothing happens with my recent build ( Intel / 10.4 ) Issue confirmed
Since native aqua fp is my terrain, I'll take this one.
@andreschnabel: OK, it's an error that the aqua implementation doesn't throw an exception. But I also consider it an error that your extension doesn't properly initialize the file picker. You may consider changing the CreatedFilePicker label to start this way: CreatedFilePicker: Dim initArgs(0) initArgs(0) = 0 oFp.Initialize(initArgs) to initialize the file picker as a simple file open dialog. For a list of possible values to supply to initArgs(0) see offuh/com/sun/star/ui/dialogs/TemplateDescription.hdl. But I will also change the fpicker implementation to initialize with this value if no proper initialization is done by a calling component.
lower priority, as the problem does not occure if the dialog is correctly initialized (as suggested by fheckl). note: there is no exception thrown, as the dialog immidiately returns with "false"
Fixed in cws aquafilepicker03. However I changed my mind and decided that if the dialog is not properly initialized from the outside, it might be better to throw an exception than to switch to a default mode (which might be the wrong type of dialog anyway). The fix can be tested with the document I will attach next. It runs the following OOo Basic macro that would just do nothing without the patch: Sub Main Dim oFp Dim initArgs(0) On Local Error Goto InitializeFilePicker ' try to create the default FilePicker oFp = createunoservice("com.sun.star.ui.dialogs.FilePicker") Goto RunFilePicker InitializeFilePicker: On Local Error Goto 0 initArgs(0) = 0 oFp.Initialize(initArgs) RunFilePicker: oFp.execute End Sub
Created attachment 59420 [details] Test case
Whatever is the mind of fheckl, the behavior of this dialog should have been consistent through various versions of oo (because some people rely on intuitive behavior). Moreover, having default behavior as being a "standard open dialog" is not so abnormal. Anyway, it is now a fact (at least in oo 3.0.0 and 3.0.1 on windows platforms as far as I experimented myself) that the initialization is mandatory. Well ok, but I suggest then that the IDL documentation clearly mention this. And that the embedded "Macro- Tools - GetFileName" be corrected : because it does not work anymore (curiously the correct initialization code has been commented out ! probably by another man who changed also his mind).
I agree that the initialization should be optional only. For one, http://api.openoffice.org/docs/common/ref/com/sun/star/ui/dialogs/FilePicker.html states that even the complete interfaces is optional, which implies there might be implementations which do not support it. Requiring *all* (existing and future) clients to check for this particular interface, and use it if present, is certainly a Bad Thing (TM). Second, and this has been raised already: Requiring initialization breaks API compatibility for existing code, and should not be done with a *very* good justification, which I miss here :)
"should not be done with" should read "should not be done without", of course
OK, then let me quote from this same FilePicker service documentation (http://api.openoffice.org/docs/common/ref/com/sun/star/ui/dialogs/FilePicker.html): ::com::sun::star::lang::XInitialization -> "Implementers may omit this interface if the FileOpen dialog doesn't support custom templates. In this case a createInstance will create an ordinary FileOpen dialog with only the common FilePicker elements. The client has to provide one of the specified constants in TemplateDescription." The aqua implementation does support custom templates and thus clients have to provide a template description initialization. Is that justification enough?
Okay, you are right in that the service description can be read this way. (I won't pick nits about the difference between "if" and "if and only if" here :) However, you did not respond to the second item, which in fact is my bigger concern: The change you did breaks (semantic) API compatibility. While that is sometimes legitimate, it should have a really good justification, which I don't see here. Defaulting to the file-open template shouldn't pose any problem, right?
Defaulting to the standard file open dialog is, of course, no problem, unless maybe the caller intended the dialog to be a save dialog, but how should I know? If you think that defaulting is better than throwing an exception in that case, then please feel free to reopen the issue :) As long as it's 'resolved' I won't change anything (and I won't reopen it myself).
If you agree that defaulting to file-open (as its done in the other OS'es implementations) is reasonable, then maybe we can implement this in the course of issue 100214 (which is what lead me here)?
Verified in OOO320_m9.
OK in OOO320_m8 and m9. Closed.