*** Issue 66178 has been marked as a duplicate of this issue. ***

changing target

*** Issue 67124 has been marked as a duplicate of this issue. ***

Is this moving anywhere?

This is a really important issue for use of OpenOffice.org in companies, since
sending part of the document is feature used many times a day.

I don't know if someone is working on this, anyway the patch I'm going to attach
can be used to add the functionality requested in this issue.

The PDF functionality is not detailed in the e-mail specification available here:
http://specs.openoffice.org/appwide/desktop_integration/send_as_email.sxw

The only reference I found in the spec is in the following sentence (row 23):

quote

When choosing File -> Send -> Document as PDF Attachment, the currently active
document is converted to PDF before it gets passed to the e-mail client.

/quote

I think that what this issue requests should be added there by expanding the
former phrase into:

quote

When choosing File -> Send -> Document as PDF Attachment, the currently active
document is converted to PDF before it gets passed to the e-mail client.
The task is carried out by showing the PDF Options window and then sending the
PDF file when the user presses the “Send†pushbutton.
The  "Send"  pushbutton  is the "Export" one with the text changed during this
service.
If  the "Cancel" pushbutton if pressed then the e-mail send process is
terminated without sending the attachment (no e-mail sent).

The PDF Options window is not brought up if the “File > Send > Document as PDF
Attachment†operation is called through scripting.

/quote

A call through scripting can have the form:

 rem get access to the document
 document   = ThisComponent.CurrentController.Frame
 dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
 dispatcher.executeDispatch(document, ".uno:SendMailDocAsPDF", "", 0, Array())

A good idea would be to add the capability to set the PDF Options through
scripting (e.g. using somehow the Array() parameter above), but this requires a
deeper change in the code. I'm willing to give it a try if you think this could
be useful.

Of course the patch needs be verified, because I'm not sure I got correctly the
export filter functionality.

Created attachment 41526 [details]
patch to add the functionality, m197 based

.

cd->beppec56: Thanks for your patch. I checked it and I think you use an
implementation detail (SFX_CALLMODE_RECORD) to distinguish between called from
API and UI. I am not sure that it always works, but you shouldn't do it. The
dispatch API is defined to be used by the user interface and therefore the
implementation should use UI as necessary. Only the normal OpenOffice.org API is
not allowed to use UI. I can accept the other part, which implements the PDF
options dialog. I don't know if you want to provide a cleaned up patch or should
I adapt your code to not use the "scripting" detection?

beppec56->cd: I added the SFX_CALLMODE_RECORD test because without that test if
you have a script code as this:

document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
dispatcher.executeDispatch(document, ".uno:SendMailDocAsPDF", "", 0, Array())

you will end up having the PDF option dialog popping up as a result of the
scripting call.
Is this correct?
If this is all right, I'll clean the code of the test and I'll rebase the patch
to m198 or m199 (m199 is building now from scratch).

beppec56->cd: I'm going to attach a modified patch:
- m199 based;
- cleaned up to not use the "scripting" detection;
- a little polishing at the few comments I wrote.

I tested it on a m199 build.

Created attachment 42063 [details]
updated and cleaned patch

cd->beppec56: The dispatch API is defined to be used by UI code. Therefore you
shouldn't use something like SFX_CALLMODE_RECORD to prevent showing UI. 
We have a different solution to support scripting using the dispatch API. The
scripting code has to provide all necessary arguments to the command then the
implementation shouldn't show any UI. In our case this would need some more work
to do (extend the slot arguments in the sfx.sdi file) and adapt the
implementation to use them. This would be an "enhancement" and the correct
target would be 2.3.

is it possible to have the script unfriendly patch in ooo asap and then wait for
script friendly patch to 2.3 ?

in our company it is really a problem now since workflow got much more
complicated due to this regression...

beppec56->cd: my suggestion is as follows:
- go on with this patch as it is (cleaned up version) and make it into 2.2.1, so
the send as PDF attachment+PDF Options functionality is again available;

- open another issue (I'll take care of it as soon as I can) about the scripting
friendly feature enhancement, adding the scripting enhancement functionality on
top of the patch I submitted here.

In case I should need more tech info about the way the scripting is managed
(code, where to act, things to have care of) is dev@framework.openoffice.org the
right ML?

cd->beppec56: Sure, you can ask questions on the framework dev mailing list.
Please give me some time as I want to be sure that the real cause of this issue
is really related to the missing code.

cd->beppec56,minimax: I checked the root cause and I think your patch is
currently the best and easiest way to fix this problem. There is one more
problem, if we want to add this patch to OOo 2.2 (minimax requested to do so).
You also changed the filter options dialog and introduce a new resource, which
is not allowed anymore for OOo 2.2 (feature/UI freeze). Do you accept to just
use only your mailmodel changes and use it for OOo 2.2. The better fix with the
text changes can be used for OOo 2.2.1?

beppec56->cd: for me it's OK to change the mailmodel for 2.2 target. Can you
take care of the changes to the patch?
Let me know...

cd->beppec56: Great! Yes, I will do all the changes (target set OOo 2.2).
Could you write a new issue and attach the text part to it. Just set me as owner
(cd) and the target to OOo 2.2.1?

beppec56->cd: will do next week.

cd: Fixed. Checked in a little adapted version.

phantastic! thanks a lot!

so i can expect this in 2.2.1 ?

cd->minimax: No, you will get the dialog for OOo 2.2. The whole solution from
beppec56 will be in OOo 2.2.1. We split the patch into two parts, because of
feature/ui freeze.

even better, ... the company that i am helping with will upgrade as soon as it
comes out because of this single feature (or fix of regression more precisely :)

cd->hi: Please verify.

Verified with cws fwk60 = ok

Still ok in 680m5 9114