Hi Ariel, Cor,
Ariel you are right. The problem is that the implementation from
PDFDialog does not provide a proper XTypeProvider interface. I will
personally punish the person who is to blame for this as soon as he
is back in the office.
While not accessible from basic, this still can be used from c++
or java. I think the best 'workaround' is to add a little java
service to the component that implements the needed interfaces
and acts as a proxy to the c++ implementation while having the
correct XTypeProvider interface.
I you need help with this you can contact me.
Regards,
Christian
Ariel Constenla-Haile wrote:
Hi Cor, Christian
@Cor: I'm sorry to be the one with bad news again :-(
Christian Lippka - Sun Microsystems Germany escribió:
Hi Cor,
try the following:
Create instance of service "com.sun.star.comp.PDF.PDFDialog".
This should support XExporter::setSourceDocument to set the document
model you try to export to pdf.
Then use XPropertyAccess::setPropertyValues to set the properties from
the media descriptor.
Then XExecuteDialog::execute to execute the dialog and on success you
can use XPropertyAccess::getPropertyValues to retrieve the new
media descriptor properties.
Not tested but this should work.
no, this won't work. At least that's my conclusion by testing this on
OOo Basic, and reading a few filter/source/pdf/*.
Both your suggestion of using the implementation name
oDlg = createUnoService("com.sun.star.comp.PDF.PDFDialog")
or using the service name available at the global service manager
oDlg = createUnoService("com.sun.star.document.PDFDialog")
instantiates an object implementing only this interfaces
com.sun.star.beans.XFastPropertySet
com.sun.star.beans.XMultiPropertySet
com.sun.star.beans.XPropertySet
com.sun.star.lang.XInitialization
com.sun.star.lang.XServiceInfo
com.sun.star.lang.XTypeProvider
com.sun.star.ui.dialogs.XExecutableDialog
com.sun.star.uno.XInterface
com.sun.star.uno.XWeak
If I understood clearly the sources, the work-flow is the one described
by you, but I can't see a way to make this work if
css.document.XExporter is not accessible for clients, as in the
implementation (filter/source/pdf/pdfdialog.cxx)
PDFDialog::createDialog() checks if mxSrcDoc.is(), and mxSrcDoc is
initialized in PDFDialog::setSourceDocument().
So if the client can't invoke XExporter::setSourceDocument(), an
ImpPDFTabDialog will never be instantiated:
Dialog* PDFDialog::createDialog( Window* pParent )
{
Dialog* pRet = NULL;
if( mpResMgr && mxSrcDoc.is() )
{
ImpPDFTabDialog* pDlg = new ImpPDFTabDialog( pParent, *mpResMgr,
maFilterData, mxSrcDoc, m_xORB );
pRet = pDlg;
}
return pRet;
}
this will always return NULL.
Why aren't XPropertyAccess and XExporter implemented by
com.sun.star.comp.PDF.PDFDialog? I didn't try to hack OOo yet, so I only
know how C++ components are design as extensions using *only* OOo API:
com::sun::star::ui::dialogs::XExecutableDialog
com::sun::star::lang::XServiceInfo
com::sun::star::lang::XInitialization
are implemented because PDFDialog inherits from OGenericUnoDialog.
If I write a UNO C++ component I would use one of the templates classes
::cppu::WeakImplHelper[N] to implement XPropertyAccess and XExporter,
don't know how you do it in the source code... but reading Frank's
dbaccess/source/ui/uno/copytablewizard.cxx you seem to use
::cppu::ImplInheritanceHelper[N]. So is the PDFDialog bad implemented?
should it be implemented this way so that XPropertyAccess and XExporter
are really implemented by the component (not only by the C++ class):
typedef ::svt::OGenericUnoDialog PDFDialog_DialogBase;
typedef ::cppu::ImplInheritanceHelper2 <
PDFDialog_DialogBase,
XPropertyAccess,
XExporter > PDFDialog_Base;
class PDFDialog
: public PDFDialog_Base,
public ::comphelper::OPropertyArrayUsageHelper< PDFDialog >
{
//...
}
From OOoBasic I can start PDF export without the options dialog.
I also can start the PDF options dialog automatically followed by
the Export dialog.
However, I would like to add path/name info to the Export dialog,
therefore looking for a way to display the PDF options dialog
without automatic Export dialog thereafter.
This is a different question as this one, that learns how to set
various options:
http://api.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1886361
@Core: to see the glass half-full and not half-empty, reading the sources
filter/source/pdf/impdialog.hxx
filter/source/pdf/impdialog.cxx
I've found *all* the properties we can use with the filter.
Besides the ones that stored in the configuration (query the node-path
"/org.openoffice.Office.Common/Filter/PDF/Export/") there are other
properties we can pass to the filer. In total (and alphabetical order)
they are:
"CenterWindow"
"Changes"
"ConvertOOoTargetToPDFTarget"
"DisplayPDFDocumentTitle"
"DocumentOpenPassword"
"EnableCopyingOfContent"
"EnableTextAccessForAccessibilityTools"
"EncryptFile"
"ExportBookmarks"
"ExportBookmarksToPDFDestination"
"ExportFormFields"
"ExportLinksRelativeFsys"
"ExportNotes"
"ExportNotesPages"
"FirstPageOnLeft"
"FormsType"
"HideViewerMenubar"
"HideViewerToolbar"
"HideViewerWindowControls"
"InitialPage"
"InitialView"
"IsAddStream"
"IsSkipEmptyPages"
"Magnification"
"MaxImageResolution"
"OpenBookmarkLevels"
"OpenInFullScreenMode"
"PageLayout"
"PageRange"
"PDFViewSelection"
"PermissionPassword"
"Printing"
"Quality"
"ReduceImageResolution"
"ResizeWindowToInitialPage"
"RestrictPermissions"
"Selection"
"SelectPdfVersion"
"UseLosslessCompression"
"UseTaggedPDF"
"UseTransitionEffects"
"Zoom"
Of course you can not use all of them at the same time ("ExportNotes" is
for Writer et al., "ExportNotesPages" is only for Impress; etc.)
Let me investigate today a little more and I tell you tomorrow
Regards
Ariel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
