Issue 100214

Confirmed for MacOSX. Should I rather create a new issue for MacOSX and link to this one or do we want 
to fix both OSs with one issue?

Hopefully we can fix both in one issue. Not sure who's in charge of the Windows
Vista file picker nowadays.

To dev team, 
Please consider also to correct the embedded macro 
"openoffice.org.Tools.ModuleControls".getFileName that does not work anymore 
under Windows OS, because of lack of initialization (since 90219 code adds).
Curiously the correct code there exist BUT is commented out.

Please consider also to correct the UNO IDL documentation : 
From a Macro developer point of view (not from a UNO developer point of view), 
there is no clear statement that now the initialization is mandatory (since 
http://www.openoffice.org/issues/show_bug.cgi?id=90219 code adds): instead the 
interface is said to be "Usage restrictions : optional".

So either the interface is mandatory, and both UNO docs and predefined macro 
"openoffice.org.Tools.ModuleControls".getFileName must be corrected, either the 
"old/historic" default behavior of opening an "open dialog" is restored.

Moreover I would say that,from a macro developer point of view, if one is not 
satisfied by the default behavior, he/she will search naturally for a way to 
modify it : anyone skilled knows that filepicker are mainly open or save 
dialogs: if open is not what is expected, one will search for the way to have a 
"save" dialog, and then will use Xinitialization.
On the contrary, having a dialog totally failing, generating an exception, is 
something that only can lead to confusion, because -versus the present state of 
the documentation and samples (MacroTools.getFileName)-, one CANNOT understand 
clearly where the error comes from (unless by reading this topic and 90219).

So anything will be better than the present situation (due to 90219 code adds).

@pierre13fr
Hopefully I can make this clear now once and for all:
Issue 90219 was there because opening the MacOSX native file picker from an OOo Basic macro did not 
work and also did not throw an error. This behavior was improved with issue 90219 by throwing an error 
when calling execute on a non-initialized Aqua file picker. Issue 90219 did NOT introduce the failure of 
the file picker not opening when called from a macro. That was there before already.

to fheckl.
Understood. So that is why I put my last comments just in this 100214 topic, 
which is Windows related. My previous comments were made to 90219 just because 
the symptoms described there are exactly the same on windows platforms, so I 
suspected a relationship in some piece of code.
So feel free to forget my reference to 90219 in my previous post.
Anyway my comments about predefined macro 
"openoffice.org.Tools.ModuleControls".getFileName that DOES NOT work on Vista/
oo301 and about documentation to clarify are still relevant.
I think that the present topic is a good place to deal with that. If it is not, 
I will open a specific bug report.

Taking over for the MacOSX aqua part.

MacOSX part fixed in cws macrofpicker01.
When do we expect the windows portion to be fixed?

Having this problem on two plarforms that need independent fixes means that this
is a collective issue. 
It makes no sense to wait for dev ressources to fix the Windows part if this
prevents the integration of the fix for Mac.

I propose the following:
Clone this issue (for the Windows only fix)
Reduce this one to the Mac fix (Adjust summary and OS field accordingly)
Get this one into a CWS to have it in DEV300 master (Good test for possible
3.1.1 integration as this one was discussed as possible 3.1 stopper in DE-dev
alias today)

Reassigned to you, please proceed.

As already mentioned, fixed in cws macrofpicker01 which is now ready for QA, but currently has no 
QARep yet. Anyone willing (it's a very small fix)?

Verified On a Intel Mac witz OS X 10.5.2 and CWS macrofpicker01 from a Buildbot.
All works well

Set myself to CC

sba-fheckl: I installed the CWS that rbircher launched
(http://termite.go-oo.org/install_sets/MacIntel-2382-macrofpicker01-install_set.zip).
Unfortunately that one crashes when trying to change Macro security level.
(Needed to alter the default level "High" in order to verify this issue...

Via menu: OOo - Preferences - OOo - Security, Click button "Macro Security" -> Crash
Note: No Crash in Sun-built DEV300m44 installation, So this is a problem of the
changed code or of the build bot build.
=> Issue repoened (this is too close to the subject of the issue...)
sba->fheckl: Please comment, thx.

fheckl->sba:
With the only code change being the following I suspect it's a problem with the build bot build. I will attach the fps_aqua.dylib from my own build to the issue so 
that you can exchange it in your Sun build and see if the problem also exists there.

The code changes are:

Index: SalAquaFilePicker.cxx
===================================================================
--- SalAquaFilePicker.cxx	(Revision 269841)
+++ SalAquaFilePicker.cxx	(Arbeitskopie)
@@ -191,9 +191,11 @@
 
     implInitialize();
     
-    // if m_pDialog is nil after initialization, something must have gone wrong before
+    // if m_pDialog is nil after initialization, something must have gone wrong before 
+    // or there was no initialization (see issue http://www.openoffice.org/issues/show_bug.cgi?id=100214)
     if (m_pDialog == nil) {
-        throw uno::RuntimeException(rtl::OUString::createFromAscii("The dialog was not properly initialized!"), static_cast< XFilePicker* >( this ));
+        //throw uno::RuntimeException(rtl::OUString::createFromAscii("The dialog was not properly initialized!"), static_cast< XFilePicker* >( this ));
+        m_nDialogType = NAVIGATIONSERVICES_OPEN;
     }
 
     if (m_pFilterHelper) {

Created attachment 62056 [details]
modified aqua fpicker lib

I can verify the mentioned problem with rbircher's build, though I don't know the cause.

Hi

I'm realy unsure that the problem comms from the Buildbot. Normaly, the Buildbot
dous realy good build, I will do now a DEV_300 m44 on the buildbot. If there is
the same problem then it's the buildbot. Other I realy think the CWS is wrong.

FYI: On Windows we are not able to build this CWS.

And I can only again just paste here the output of
svn diff svn+ssh://svn@svn.services.openoffice.org/ooo/tags/DEV300_m44 
svn+ssh://svn@svn.services.openoffice.org/ooo/cws/macrofpicker01 


Index: fpicker/source/aqua/SalAquaFilePicker.cxx
===============================================================
====
--- fpicker/source/aqua/SalAquaFilePicker.cxx	(.../tags/DEV300_m44)	(Revision 271609)
+++ fpicker/source/aqua/SalAquaFilePicker.cxx	(.../cws/macrofpicker01)	(Revision 271609)
@@ -191,9 +191,11 @@
 
     implInitialize();
     
-    // if m_pDialog is nil after initialization, something must have gone wrong before
+    // if m_pDialog is nil after initialization, something must have gone wrong before 
+    // or there was no initialization (see issue http://www.openoffice.org/issues/show_bug.cgi?
id=100214)
     if (m_pDialog == nil) {
-        throw uno::RuntimeException(rtl::OUString::createFromAscii("The dialog was not properly 
initialized!"), static_cast< XFilePicker* >( this ));
+        //throw uno::RuntimeException(rtl::OUString::createFromAscii("The dialog was not properly 
initialized!"), static_cast< XFilePicker* >( this ));
+        m_nDialogType = NAVIGATIONSERVICES_OPEN;
     }
 
     if (m_pFilterHelper) {


And you can verify this easily, you don't need to have the sources checked out. So if you are unable to 
build this cws on Windows, I wonder if you can build a plain DEV300_m44 on that platform.

I saw this one working in CWS built by PL.
Set to "Verified".

Note: To get this fixed for Windows Vista too, see issue 101774.

OK in OOO320_m8. Closed.