Thanks for you guidance Tim. After reviewing I am coming to the same conclusion.
> This is trickier than you might guess. Does the application actually > write to the printer using a Windows printer driver? Some old > applications that just used a printer for logging wrote directly to the > parallel ports. That kind of thing is almost impossible to trap. If it > does, how does it pick the printer? The application is quite "configurable". Printers can be configured so the application to write to either a port (including UNC path), a Windows print driver or directly to a file that is specificed within the application. We typically use the "generic/text" driver to define the "windows" printers, however, just pointing the app to "LPT1:" works just fine too. If it doesn't present you with a > dialog, then it might be picking the printer by name. That means you > can't just install your own driver, unless you use the same name. If it > does present you with a dialog, can you use the Generic / Text-Only > printer driver, and have it dump to a text file? (That's one of the > standard printer drivers built-in to Windows.) I have thought of the Windows printer defined as "file" however, I don't want the user to be prompted for the file name each time and haven't found a way to suppress this. > If you really need a driver, you are not going to be able to do this > from Python. There are a sample printer drivers in the WDK (Windows > Driver Kit). It is not a project to be undertaken lightly. Yes, I am starting to understand that :-( What we are trying to do is capture the printing "dynamically" while the user is running the application ( -- think of invoice printing in a business). The app output is text, with some printer control codes embedded to change fonts, colors, newlines, etc, but other than that it is just ascii text printed line-by-line sent to the specificied port or file. The problem we see with the "print to a file" approach is we would like the system to react immediately when the user "prints" and having some sort of "polling" to watch the file isn't the best solution as it introduces a delay/latency. One option I was considering is using Windows printer defined as a "Standard TCP/IP Printer Port". Our thinking is to manually configure a printer in Windows and then use the LPR or RAW method of this print monitor to redirect the output to our program via TCP/IP. Haven't tested this , however, the thinking is that this would tell us immediately when the user is printing and our utility could re-act accordingly. Any thoughts or comments or guidance would be truly appreciated. g. _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32