Using the SendObject action in a macro, you are limited to the options that
Microsoft provided. You can call a function to generate a .pdf file from a
macro, but why bother with the macro in the first place; just use some VBA
code behind a command button to generate the .pdf file directly, which gets
saved into some pre-defined folder, such as C:\Temp, or some TempOutput
folder that is child to the folder that your application is in.
Using Stephen Lebans' ReportToPDF method will allow you to save the report
as a .pdf file in some type of temporary output folder, usually on your local
hard drive. Then use VBA code to create an e-mail message with this new .pdf
file attached. Arvin gave you one method. Take a look at this thread from
yesterday for another method:
http://www.microsoft.com/office/com...ovba&mid=adcd572b-2052-45c3-a197-5e37af6cf082
Regarding the use of macros....
In Access 2003 and all prior versions, one cannot trap for errors and handle
them gracefully when using macros. Any errors that occur will cause a really
ugly macro error dialog to be presented to your users. The newest version of
Access, Access 2007 allows for error trapping, so macros are more appropriate
to consider using for Access applications created with Access 2007.
Consider the following quote:
From: "Inside Relational Databases, 2nd Edition, by Mark Whitehorn and Bill
Marklyn, published by Springer, p 151
"Macros offer the next level down, extending the functionality of the GUI.
Macros are still limited, however, and do not provide anything like the
enormous flexibility of a programming language. Both the macro and the
programming languages take some effort to learn and, surprisingly, often
require relatively different skills; in other words, a good working knowledge
of macros may not make it much easier to convert to using the programming
language. Perhaps even more surprisingly, I do not believe that programming
is fundamentally more difficult to learn. Macros are easier to use but not by
orders of magnitude."
"If you are new to RDBMSs, I suggest (with as much deference as possible)
that you may well not be in a position to judge whether you need macros or
programming. In that case, my advice is clear. Unless you are sure that your
needs really are simple, don't bother learning to use macros. Once you find
that you need more than the GUI offers, go straight to the programming
language. In this way you avoid the pain of climbing one learning curve only
to discover that the view from the top is unsatisfactory and another climb
awaits you."
Good Luck,
Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________