>>Hugh's suggestion is indeed quite an interesting approach. But, the problem I have is that, this is a "Point of Sale" application that sends many "print Jobs" (work tickets, delivery tickets, cards, labels) simulateneously and directly to different LPT ports (up to 9). So, making the procedure manual by having to print from a browser unfortunately is not an option.
>>
>>I have the ability to save/restore the entire Escape Sequences of a particular printer model in the application, and it has been working OK, all this time with Laser printers, but now with later model Inkjets particularly, it is now hanging the system.
>>
>>So, for those folks who still have to support "Coded Reports";
>>1) Has anybody had better results with loading a partilcular Driver for InkJets?
>>
>>2) Is there a "better" set of Escape Codes for InkJets? (I still use LasetJet codes)
>>
>>3) Any other ideas?
>>
>>Cheers;
>>Cyrus
>************
>We have a similar problem. Unfortunately we have thousands of customers still using a fpd26a app and it will take years (probably) to get them to convert. Our dos printing methods generally failed with WinXP (not with all computers?) so we ended up taking the printing code from our VFP7 version and creating a new project and a standalone EXE from it. We then run the EXE from the dos program like you would run any other EXE. We pass the filename to be printed as a parameter. It works. We are using code that resembles the DIRPRTCLASS.PRG code in the UT library. We were using rawprint (which we liked better) but it messed up with very large files (we never figured out why). The DIRPRTCLASS.PRG code works well, except when the page is mostly filled with text it is followed by a blank page. The exact same file printed the old copy to lpt way in Win98 prints correctly so it is a problem in the dirprtclass code - we think.
>

This is the first I've heard about it (and I wrote the class!) - I assume you're using the SpoolFile() method of DIRPRTCLASS to send the output to the printer. My guess is that it's a spooler behavior, selected via the Windows Printer dialog in XP (right-click, select Properties, the Advanced Tab, Print Processor button - I'd bet a nickle that the printer is not using WinPrint, or is using a spooler data type other than RAW, so the spooler is stepping in and adding a behavior you don't want, given the error you describe. That's fixable; the SpoolFile method is pretty just a wrapper on AddJob() and ScheduleJob(), which uses either MoveFile() or CopyFile() to assign the file to be printed to a spool file name returned from AddJob(). With large amount of memory available, it's possible that you are using an old version of ClsHeap which contained a flawed DWORDToNum() UDF - the current version on UT has been correct for well over a year now, or that your own replacement for the the function also results in a miscast value for a hex value represented as a value of 0x80000000 or larger, which needs to be cast as a negative value, since there is a difference in how VFP represents 0x80000000 and BITOR(0x80000000,0) - the first is stored as a real, the second an integer, the first has a positive value outside the bounds of the INTEGER datatype.

I'd tend to suspect that the Spooler is not handling the spool job as RAW through WinPrint. I've seen some broadly wierd spooler behavior where the data type was EMF or PostScript, or some third-party spooler replacements were in use. I've also seen the same behavior with networked printers whose host spooler was not WinPrint or a RAW format, too.

>As far as the escape codes, we have the same problem there also. They work with some bubble jets but not with most of the newer ones.
>

How about using PostScript output, with GhostScript (a GNU tool that provides a PostScript to native printer code translator) handling the nastiness of the printer driver? That moves the resolution out from the Fox app (there are PostScript drivers back as far as DOS via PDSETUP) and into the realm of correct installation of GhostScript, or the use of printers with native PostScript support built-in.