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.