>here's the scenario:
>I am running a VFP 6.0 app in Win98 on a Novell network
>
>the user picks one menu choice that involves creating
>a cursor and 2 forms but no reports, then they select
>another option that prints a report. this works ok,
>but then if they try another option thats call another form,
>the system crashes - big ugly blue screen of death, message fatal exception error, etc basically lights out - requires complete reboot!.


******************************

I have the same problem with many many customers. It is a problem with Hewlett Packard Printer drivers. With some help from Microsoft Product Support, we have traced the problem. If you install Hewlett Packard's own printer drivers for their printers, it creates a problem.

Here's why: HP, instead of using the native floating point processor on your computer's motherboard, it emulates a floating point processor in memory. This was the way floating point operations were handled in the days before we could assume that every user had a floating point processer on board. Of course 486 and Pentium processors have the FP processor included on the processor chip.

Visual FoxPro assumes you have a 486 or better computer, that the FP processor is native, and so issues calls to it.

If you print anything, preview, SET PRINTER TO, etc. and it calls an HP driver, HP resets the computer to emulate a floating point processor in memory. AND IT DOES NOT RESET IT BACK TO THE STATE IT WAS WHEN IT IS FINISHED. VFP, expecting the FP to be native, tries to do some operation at uses it, and VIOLA! system hang, big blue screen, lock up, and all that other _*&@)$*@&)(*@!# stuff.

Microsoft will fix this in the next release of VFP 6 -- Service Pack, or whatever. Jim Saunders at Microsoft Visual FoxPro Support gave me the followint workaround and IT WORKS!!!!! He writes:


Hi Richard,

We are _very_ aware of this issue. We thought we had addressed this in VFP6,
but apparently did not solve the problem as well as we had hoped. We are
working on addressing this from a VFP product standpoint in the next release.

Iworked on a case with another developer with the same issue last week. We
were able to make his app function without hanging. Here is what we did:

Added this to the beginning of the main program:

DECLARE _fpreset IN msvcrt20.dll

We addedcalls to _fpreset() after each:

SET( "Printer", 2)
SET( "Printer", 3)
REPORT FORM ...
SET PRINTER TO NAME

Also add a call to each report's dataenvironment BeforeOpenTables and Destroy
method.

Also add _fpreset() immediately after either of these, which this other
developer was not using:

GETPRINTER()
SYS(1037)

We found we also needed to add _fpreset calls to the end of the Load and
Destroy methods of the form from which his app did all its printing. Once we
did this,the app would work without hanging or crashing.

Please try this approach and let me know how it works. If this does not fully
address the problem in your app, let me know and we will look at it further!

Jim Saunders
jimsau@microsoft.com
Microsoft Visual FoxPro Support
(704)582-8115 (direct line)
Hours: 9:00am - 6:00pm EST

My manager's name is John Yakob.

*******************************************************

I developed a brief program to poke these lines into the dataenvironment of all reports. If anyone wants it (it will save a lot of time) .. email me:

rscarter@microserve.net