Gee, I never heard that one in all the time I spent in Morehead City/Beaufort. g Say hey to Kevin for me.

Back to your attachments issue: The devil is in the details, and the details in this case are -- what kind of file is the attachment? If it's a text file, it's a pretty simple operation to use FileSystemObject methods (http://www.microsoft.com/technet/scr..._scr_xfxi.mspx) to append to a text file. In other words, it's not Outlook that has methods for combining text data, it's FileSystemObject. And you can automate FSO in Outlook code just as you can automate Outlook or Excel or any other application with a programming library.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx


"SFC Charlie Cox" wrote in message ...
Ok, this is now officially kicking my bahawmpuss (a southern term unique to
Down-Easters in North Carolina.

Let me try a different tack.

I can select the attachment and save that where I want, no problem.

I can save the email itself as a text file where I want, no problem.

How difficult would it be to get outlook to combine the two (appending the
text version of the email data to the attachment file) and then save the
combined file?

Does that make any sense to you? Then I can use the Excel logic I've
already developed to parse the data.


"Sue Mosher [MVP-Outlook]" wrote:

No, it just means that the code to process the file isn't Outlook automation code. It may be code running behind an Outlook form, but it's using programming libraries other than Outlook.

"SFC Charlie Cox" wrote in message ...

Additionally, you mentioned that the only thing Outlook can do with a file
is save it as a file. Does that mean code embedded in the form cannot open
the file, parse it with the additional data from the form and then save the
file with a different (user specified) name?