I *think* I have it running correctly now. Will test in the next few days when the client gets back, but I had to uninstall everything (printer/pcie card) and setup with new versions of drivers, no longer using generic/text only, but the Okidata driver. Also changed a printerisolationmode setting in group policy to off, which supposedly is for legacy print drivers. I don't know if that's what did it; I suspect it was using a different print driver. I also reloaded printer codes in SBT to OKIdata, which I noticed were very different from what was loaded.

Thanks to all who helped me work through this problem.


>>autoyield should be set to the default .t. so I don't think that should be a problem.
>Unless there was a change made if you had made use of ActiveX controls, in which case you might have AutoYield set to .F. to avoid certain problems with event capturing (e.g. things like OKLs and the like don't work right). Mainly mentioning this as this was one of the things that bit me when we started seeing WinModems, USB modems, and USB-to-RS232 adaptors in use. These tend to use software to service these devices (instead of having dedicated hardware to handle specifics of transmission). -- meaning that if your program doesn't give up its timeslice frequently enough (usually you can do this with some form of I/O or DOEVENT -- basically anything that would access the event queue either explicitly or implicitly), these devices tend to freeze up.
>
>One other thing that was a frequent problem with USB-to-whatever adapters, they usually work fine in 32-bit, but don't work at all in 64-bit (mainly because the 64-bit driver was non-existent, or was buggy). In most of the cases when we were able to get the customer to install an actual RS232 I/O card the problems we were having would "magically" go away (not that it surprised me, but everybody else at the office seemed to be mystified).