Thanks for the reply Jim. I discovered why PASSTHROUGH does not work as expected. The PCL driver appears to buffer output and invoke WritePrinter when it's output buffer is full (or crossing a page boundary). PASSTHROUGH simply calls WritePrinter directly and bypasses any buffered output. When the output buffer is finally flushed, it now follows the PASSTHROUGH data in the printer data stream.
I've come up with a different solution that seems promising. My app needs to turn printed output into a PCL Macro, so I print to a file. I must post-process this file to insert the macro definition commands, and to remove reset and UEL commands. I use GDI to 'print' my PCL escapes to force them into the print stream relative to other elements being printed. I use an escape 'placeholder' (currently 0x7f) because the PCL driver won't allow an application to print an 0x1b escape identifier. Then, during post-processing, I identify my escape placeholders and change them to the 'real' 0x1b escape identifier. There are two issues with this technique that must be addressed. First, the post-processor must ignore dynamic binary escape data (such as raster data) so it does not falsely interpret the escape placeholder. Second, the driver will clip (remove) any text that would fall off the page if printed. When 'printing' the PCL escape placeholder and data, I make sure this 'text' will not fall off the page by adjusting my horizontal print coordinate and embedding an equivalent relative cursor adjustment escape with the other escape data I want to insert. So far so good...
Regards,
Vince
