Hi Raoul,

This is just a followup to anyone who is following this thread...(and if Raoul has any more thoughts)

The first two KB's listed below are orientated to solving a problem when an error occurs *after* the print job has happened. In brief, this is what they are saying:

1) There is some error handler in the numeric processor that handles hardware related errors
2) Printer drivers also make use of this and they are supposed to reset it (probably to zero) after they have finished their work
3) Some HP drivers do not properly reset it
4) The next time an *numeric* error occurs in FoxPro (divide by zero is their example), things are not set up to handle this error since the error handler has not been reset (see Q183522 which goes into details of this - I am keeping it simple here and therefore, the details I give are incorrect in specifics but correct as an overview). This error triggers a fatal error.
5) Their solution is to reset the numeric processor after every print job "manually" by calling

_fpreset() IN MSVCRT20.DLL

6) This probably is a solution for a divide by zero error.

In my case, it did not help. I tried resetting the processor before and after the print job but kept getting my "Pure Virtual Function Call" error.

I think it did not help in my situation is that the error is not a numeric error that is supposed to be handled by the numeric processor - it is another print driver error. I also think that what is happening is that the driver loads, calls the "Virtual Function" (incorrectly) and this triggers a fatal error. It has nothing to do with the numeric processor. And therefore it cannot be "cured" by resetting that. Looking up on MSFT what a "Pure Virtual Function" is, the solution they give is that the program (the printer driver in this case) is incorrectly calling a function and it needs to be fixed.

The long and the short of it is that HP needs to fix the driver.

FWIW, I am going to also go back and strip out the "PROMPT" clause from the REPORT FORM command and see if that is liveable. Cannot see why it would be though because we still have to call the print job to get the printing done and if there is an error in it, it will still bomb. But maybe this will help because I notice that when the FP Printer Dialog loads, it queries stuff in the driver (status etc) and so maybe one of these queries is the problem. (Who the heck knows!)

Albert

>Take a look MS KB articles: Q183522 and Q253356. You might also want to look at Q125749 for the cause of the "pure virtual function call error". It's my understanding that it's in the driver.
>
>Basically, HP drivers tend to violate some of the DDK specs.