On 21/07/11 12:19, Michael Meeks wrote:
Hi there,
I was wondering why:
sc/source/ui/vba/vbaapplication.cxx
and
sc/source/ui/vba/vbafiledialog.cxx
had this complicated duplication of this big ugly block:
I have *no* idea, even though I committed this code it is not ours ( it
was a contribution of new api ), you would think the Application object
would use the FileDialog object ( or at least share the implementation
if not )
[...]
AFAIR only those two services implement xFilePicker2 anyway - so it
-looks- to me as if all of it is redundant except for:
if ( xFilePicker2.is() )
which of course we should always prefer.
Any idea why that heavy-lifting service name check is there ? I'd like
to bin it from both places: in future all fpicker services should use
XFilePicker2 (ideally).
yeah, I agree if XFilePicker2 is available then it should be preferred,
the code here seems to purposely try and do the opposite except for the
2 exceptions above. I wonder was there some instance where XFilePicker2
methods were not behaving for some other filepicker instance, other than
that I see no reason to keep that check
Noel
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
