>The first thing I'll try is the LP 4Plus to see if it is the driver causing the problem. This is crazy -- I was just sitting here and I recalled that another client has been complaining about one of their computers locking up!! They kept thinking it was a virus or something wrong with the computer -- but they were having the problem in a VFP6 system and that computer is connected to an HP 4000 printer [just the basic 4000 - not Postscript or network ready].
>
>If it is the driver, are you saying that for right now, there is not an updated printer driver [for the HP 4000] from HP or MS that corrects these problems? In other words, they must continue to use the driver that works [i.e. the HP 4Plus driver]. I don't see this as a major problem -- however, I don't know how the network staff at the client is going to feel about this.
>

I've never investigated an updated driver from MS for the 4000 - I know that HP's causes problems, and that the site I had with the 4000 problem switched to the MS-provided HP 4 driver from the NT server distribution. I'm not certain what, if any, features you give up using the MS-supplied driver for the HP 4, but from my POV, a working driver that provides all of my client's requirements but isn't as pretty or feature-rich as a vendor supplied driver that causes problems is an easy choice. I fixed my client's problem, showed them how to fix it if they broke it again, and haven't gotten any complaints since, so either they're happy with the HP 4 driver or they got one that finally worked.

We use HP 5si printers at my office; until we got a stable MS-supplied driver set for the 5si, we used the HP IIIsi drivers. None of our staff using the production systems complained about it. I'm pretty compulsive about testing new video and printer drivers in-house before putting them on our own production systems. In the long run, it costs a whole lot less to use a known, stable driver and test new drivers before using them than to spend time chasing my tail because the newest, lastest, hottest drivers smoke an application, even more so if we don't have the source for it.

When I get reports from the field involving HP printers, the first thing I do is to have the client switch drivers to one from an MS distribution CD for their operating system, and if it works, offer the client the option of using the MS drivers while bitching at HP to get them to fix things, or pay for me to find a workaround, since it's been an ongoing and consistent problem with HP drivers. I'm not on the line as their hardware vendor and if I can prove out the problem isn't in my software, they can either pay me to pursue a fix to let them use HP's drivers at their expense (in most, but not all, cases, the _fpreset() fix works), get a different printer that I know has stable drivers, or use a driver that works with their printer.

I'm reluctant to blame hardware or drivers unless I can prove out that they're the source of the problem, if for no other reason than it makes me look lazy and stupid when I'm wrong. Once I can prove it's something hardware related, I can point fingers at other vendors with the best of them...

SP3 fixes some of the HP print driver problems that occur because of (IMO) HP's apparent inability to handle the CPU when returning from their driver (again, not all of them), so that's another avenue to pursue now.

>Thanks again for the response -- I'm anxious to get to these clients on Tuesday and see if this is the problem.
>
>Doug