>ed -
>
>thanks for your recommendations. i'll be trying those classes.
>
>my real and original object was to be able to open and print a text
>file from VFP. i could not find an app like notepad or wordpad
>that is an OLE server. (maybe i didn't look hard enough or didn't
>look in the right place).
>

If the file ends in a .TXT extension, then either NotePad, WordPad or MS Word will be used as the Windows file handler for ShellExecute(); you could invoke the ShellExecute() API call with the PRINT command instead of the default OPEN command, and whichever app is designated as the server in the File Type entries in the registry will be invoked automagically. There's a class in the FFC which serves as a wrapper for ShellExecute, called _ShellExecute, in the _environ.vcx classlib in the FFC subfolder of VFP, and sample code for using the API call directly in the WinAPI section here on UT.

>what i ended up doing in the meantime, was to create a table called
>TEXTBL with 1 field called io_line C(100). i fopened the text file and
>read each line with FGETS, appending each line as a record to TEXTBL.
>
>then just did REPORT FORM rpt_TXTRPT TO PRINTER PROMPT NOCONSOLE, where
>the report rpt_TXTRPT just has a detail line with one full-width field
>for io_line. (no grouping, labels, headers, or footers).
>

You could simply invoke a DirectPrintOutput instance and write directly to the spooler using DocWrite(), or use the SpoolFile() method to queue up an instance of the text file in the spooler. This is exactly what the class is designed to do. It bypasses the GDI, so whatever is written to the spooler is not reinterpreted by the GDI layer of Windows - this means you are responsible for any printer control sequences and the like you need in your output. The spooler will not add things like page feeds or reinitialize the printer before sending your stuff; it's a pure raw write.

>crude, but simple. talk about going around the barn 3 times to get in
>the door.

The class should handle this directly; ShellExecute() will invoke the file type application for printing, but it will likely go through the GDI and use the default font for text files set in the application.