re Delphi 4 Std

My application is causing a fatal error - Invalid Floating Point operation.

The procedure which is causing the error has no real calculations, no real
variables defined and use no real variables.

Any ideas?

TIA

Source text in studio !!!

Vladimir
Kononov

news:rDBD6.110638$g63.13274414@nnrp3.clara.net...

I'd guess that it's a Delphi problem*, not one of your coding problems.

Are you stepping through your program with F7's and F8's, with several
expressions in the Watch List? Pare down that Watch List to perhaps a dozen
expressions and see if you still have the Invalid Floating Point error. The
Floating Point error is caused by some timer variable getting too big. The
more time that it takes Delphi to fill in your Watch List, the more likely
you are to get this error.

*Some say the problem is a Windows problem, but that's immaterial, AFAIK -
it only affects Delphi.

"Bob Richardson" <b...@whidbey.com> skrev i melding
news:tdu7jkaca53p06@corp.supernews.com...

I *believe* this problem has to do with combination IDE debugging <-> display
driver - ISTM that this allways occurs in code involving GDI calls
(painting).

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

No the error occurs on certain machines and is caught with my global
exception handler.

I know which procedure it happens in as to try to track the problem down I
have added numerous ShowMessage's.

So it happens at run-time not whilst debugging with F8 etc.

I can not reproduce on my set-up which makes it even more difficult.

Any further ideas?

On Thu, 19 Apr 2001 19:56:09 +0100, "NoSpam" <nos...@nospam.com>
wrote:

Can you narrow it down to a few lines, and post those here?  You might
be doing floating point operations unintentionally.

One common place to have this error show up is in the rounding
functions, which you may be using even though you don't intend to.  If
some other buggy code messes up the floating point registers, then
those routines are likely to blow up.

One thing that might fix it is to put

 Set8087CW(Default8087CW);

into your code before the spot where it blows up.  This will work if
it's the control word that got changed.

It's also possible that code leaves floating point exceptions
triggered but doesn't handle them; I think

  asm
    fclex
  end;

will clear those (but I haven't tried this particular solution).

Duncan Murdoch

I've seen a floating point error (log(negative number) that occured
earlier in code not actually show up until later.  I was even able to
have the program give several showmessages beyond the point where the
error was actually taking place.

On Fri, 20 Apr 2001 13:46:15 GMT, spa...@umich.edu (Steve Parus)
wrote:

That's what happens when the control word is changed to mask errors,
and later changed back to unmask them.  Video drivers or poorly
written DLLs will often make the first change; the RTL will make the
second change.

Duncan Murdoch

Should / can I use Set8087CW($133f) to disable this checking?

On Fri, 20 Apr 2001 18:52:48 +0100, "NoSpam" <nos...@nospam.com>
wrote:

I don't know, but I'd give it a try.  At least that way the RTL will
know that errors are masked.

Duncan Murdoch

I have tracked down that the command trunc seems to be causing the problem.

I am gradually going through the program and if I remove the trunc command
(which I could in some places as the result was always an integer - i.e.
using "div") the problem at that part of the code went away.

However, I can not remove the remaining trunc commands as real division is
being carried out.

Any ideas what could be causing trunc to fail?

Delphi 4 Std

"NoSpam" <nos...@nospam.com> skrev i melding
news:QHxE6.119944$g63.14038291@nnrp3.clara.net...

An invalid float number. I don't know too mauch about this, but I see from
time to time that uninitialized float variables (containing more or less
random bit patterns) may cause errors.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

On Sun, 22 Apr 2001 10:41:53 +0100, "NoSpam" <nos...@nospam.com>
wrote:

Besides the possibilities others suggested that Trunc is actually
getting bad data and failing for that reason, I'd look for other code
messing up the FPU.  Trunc is one of the functions that is sensitive
to that.  

Here's a couple of routines that can detect a messed up control word:

function Get8087CW:word;
begin
  asm
    fstcw result
  end;
end;

function Okay8087CW:boolean;
begin
  result := ((Default8087CW xor Get8087CW) and not $E060) = 0;
end;

Put

assert(Okay8087CW, 'Someone messed up the control word!')

just before the bad call to trunc, and compile with assertions on
(i.e. {$ASSERTIONS ON} at the start of the unit, or the compiler
option checked).  If the assertion fails, then a workaround is

Set8087CW(Default8087CW);

just before the trunc, but what you should really do is track down who
is messing up the control word, and fix that.

Duncan Murdoch

The message <QHxE6.119944$g63.14038...@nnrp3.clara.net>
  from  "NoSpam" <nos...@nospam.com> contains these words:

Hi,

Someone else mentioned the exact same problem with Trunc a few weeks ago,
either in this group or alt.comp.lang.borland-delphi. The conclusion, seemed
to be that Trunc is intended to operate on Reals and not on integers.

I think it ought to produce a compiler warning of some kind, I am sure that
to fix it so it makes no difference costs extra CPU cycles.

--
Sincerely,

Andreas Kyriacou
----------------
http://www.andrikkos.co.uk (Imagine! Image Viewer)

This may be a leetle bit off topic, but I've had a similar sort of thing
occur using D4/5 on Win98 when I'm playing with FormatDateTime() and
stuff like that...

J.