_fpreset() in Reports?

[Headwinds]

I'm in the process of upgrading a large application from VFP3 to VFP6. When I try to run a report, a messagebox tells me that FoxPro is "unable to find _fpreset.prg". Sure enough, there's a field on the report that says "preset_____". It's there in the VFP3 version also, but isn't visible when the form runs.

Using the report editor to remove this field from the VFP6 version of the app doesn't fix the problem. The only way I've found to get the report working is to open the *.frx file as a data file, mark the record containing the reference to _fpreset for deletion and pack it. Here's what's in the record I'm deleting:

Platform:	WINDOWS
Uniqueid:	_0B80TNCSE
Timestamp:	709246728
Objtype:	18
Name:		preset
Expr:		_fpreset()
Unique:		F
Tag:		0
Totaltype:	0
Resettotal:	1

All other columns are empty.

I'm guessing that all this has something to do with resetting messed up floating point operations. My questions are:

1. What risk am I taking in removing this item from the report definition?

2. If I'll lose something important by deleting it, how can I restore proper functionality in the VFP6 version?

3. What's a report objtype 18?

4. How did this invisible field get into the VFP3 report if I didn't intentionally put it there?

Thanks in advance for any assistance you can offer,

Jim

 

[SGLong]

Jim:

It's been a while since I ran into that - back when I converted APPs from FP2x to VFP6.0, but it has something to do with resetting your floating point math setting that gets used when running reports. We were noticing all sorts of weird problems until we started using _fpreset().

I'm sure someone else will be able to tell you where this file/function can be obtained from, but I'm pretty sure it's part of the Visual Studio package.

Steve

 

[Headwinds]

Here's what I've learned about this. _fpreset() is a function that lives in the Microsoft Visual C++ runtime library MSVCRT20.DLL. You can make this function available to a Visual FoxPro program by issuing "DECLARE _fpreset IN msvcrt20.dll". Once that's done, FoxPro can call _fpreset() to reset the numeric coprocessor after it's gotten trashed by dividing by zero.

Apparently several non-Microsoft printer drivers (for example, one for the HPLJ4000) caused blue screen Windows crashes when FoxPro tried to print a report. Microsoft's short-term fix was to tell everybody to call _fpreset() whenever doing any kind of print activity.

Visual Studio 6, service pack 3, is said to fix the problem, so we probably don't need the calls to _fpreset() in our reports any more. Relevant MSKB articles are Q253356 and Q183522.

This still doesn't explain why upgrading from VFP3 to VFP6, SP 3 suddently causes "Can't find _fpreset.prg" errors. It's probably got something to do with the fact that we've simultaneously moved from Win95 to WinNT4 workstations (but we've still got MSVCRT20.DLL in \WinNT\system32).