Hi Duke,

Don't mind the rant at all...it's nice that I am not the only one steamed over this. We have been an HP shop ever since the original LJet came out and we currently have 10 larger HP's (HP 4 to HP 5si), a bunch of IIIp's from the stone age and another wack of inkjets. I have stuck with them for the 7 years that I have been the MIS guy because as a piece of *machinery*, they seem darn good. But you are right, if the driver is no good, it means diddley and all that happens is that I look like a schmuck programmer because it seems to the users that I cannot solve programming problems.

So I get on the phone in a few minutes and reopen the case with HP.

BTW, I took out the "PROMPT" clause this morning (since there was only one that worked like this) and tried it on the user's PC. I only had faint hopes of it working. And the very first try, I got the dreaded "Pure Virtual Function Call" error and the machine shut down (the app shuts down first but then I find the machine is flakey after that and they have to reboot regardless). So stripping PROMPT does not help. I should just memorize "It's in the driver, stupid" and keep saying that to myself (and to anyone else at HP who listens).

The one tester gets about 80% of her print jobs if she uses an older HP 4 driver (with no crashes, thankfully) whereas the other tester gets about 80% good results with an HP 5 "Standard" driver. If these were 100%, it might be a short term solution but even they cannot be relied upon. And anyhow, do we really have to drop back to older drivers to get printing under VFP?

One thing I wonder though is why there is no problem printing under Word or Excel with these drivers? Do the dev teams for these products know how to do the function calls to the drivers better than the VFP dev team? Or is it that VFP is calling them correctly thus exposing errors in the driver?

Thanks for your comments...I'll keep you posted.

Albert

>Obviously, something's misbehaving when using the PROMPT clause in report command. I'm just wonder, however, if accessing SYS(1037), GETPRINTER() or even the the Common Dialogs ActiveX control's printer functionality would cause the same problem. This sort of behavior makes me very upset with the provider.
>
>< DukeDaddy metamorphosizes into "The Duke" >
>
>The Duke says this. The Duke says that he'd like to get the Senior Developer for the printer drivers from HP into a room along with one of those well engineered, well manufactured, HP Laser printers that's as big as a microwave oven. The Duke would then explain to that rooty-poo that those well engineered, well manufactured, HP Laser printers that are as big as a microwave oven aren't worth a pile of steaming monkey crap if they don't have drivers that conform to Microsoft's DDK specifications. If he protested saying that he didn't think it makes a difference, the Duke would tell him in no uncertain terms that, in the final analysis, It doesn't matter what he thinks. The only thing that matters is that the well engineered, well manufactured, HP Laser printers that are as big as a microwave oven work as they're supposed to. The Duke would then take that engineered, well manufactured, HP Laser printer that's as big as a microwave oven, turn it sideways, and stick it straight
>up his candy...As you can see, the Duke gets slightly aggitated about this subject.
>
>The Duke humbly apologizes to you for this rant.
>
>Hey, folks it's Friday. Remember "Fun Fridays"?