1. Yes, it was running vfp7 on the old computer. That conversion was done many years ago. I can't remember if it was in vfp5 or even vfp/windows 2.5... and yes, it used to run fine with the same configuration on WinXP.

2. I can't set a default printer with win printing because it's using a bunch of @say (or !!) statements...not report forms. I haven't even really dug into that code for a couple years so I don't totally remember. I just know that it either won't be a code problem or it would take a full rewrite...I wasn't interested in the latter option.

3. The interesting part is that the old computer was using a generic/text driver, with winprint(RAW/FF added) for the print processor. What seemed to work was converting this to an actual Okidata driver. Yes, dot-matrix printers are quite exciting to use in Win7, I'm finding. Especially given new computers don't even come with LPT ports installed anymore.

In any case, it appears to be working now. Time will tell if it can handle the large reports in coming days.

Thanks for the response!

>A few questions/comments:
>
>- You say the SBT source code is running in VFP7. Was it also running VFP7 SBT on the old computer, and printing properly, or was a conversion to VFP7 done at the same time as migration to Windows 7? IOW has the SBT app been known to print properly when running on VFP7, on the old computer?
>
>- If it's a VFP7 app, running on Windows, you should not have to mess around with LPT: ports at all. You should just be able to set your (default) printer, and run your reports.
>
>- If you had successful printing with the old system (on VFP7 and an earlier version of Windows), what printer driver, and its settings, were used there?
>
>I have one client running dBASE-IV style FPD2.6 code on VFP5, with a lot of unconverted FPD-style reports. The reports were defined with the DOS-style printer drivers, and used PDSETUP to select 10/12/17cpi, bold font etc. I switched their code to VFP5 during the Y2K era. At that time they were still using some dot matrix printers, and I had trouble getting them to work as expected. It was a long time ago, but ISTR needing to preserve the FOXUSER resource files from the old DOS version, because it contains a lot of printer-related info for those types of reports. But I think there was another issue converting those resource files to VFP5, because FPD and VFP5 resource files are not the same and I'm not sure if they're even backwardly compatible. IAC if your underlying code/reports uses a similar base structure, and you're trying to still print to dot matrix printers, you're in for some fun.
>
>>If I hit "print test page" in the Generic/Text only properties, it prints immediately...
>>
>>I also double-checked - autoyield is set to .t.
>>
>>>Unfortunately, I need to reopen this thread as the PCIe adapter behaves the same way. One other bit of info with the lpt card. When I print (and this can also happen from the dos line with "dir >lpt1" - the document will quickly flicker in the print queue, then go away. If I change the print driver to print directly to the printer, rather than spool, it will hang in the print queue until I take the printer offline. Then I can delete.
>>>
>>>Frustration!
>>>
>>>
>>>
>>>>>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).