Floating Point division by zero exception handling in DLL's (Delphi 1.0)

I am having serious problems trapping the floating point
division by zero exception within DLL's in Delphi 1.0.

It seems to work fine in Delphi 2.0.
It also works fine within the program section of Delphi 1.0.

Here is some stripped down code:
Code to Call Form from Application in DLL.

  Proc = procedure;

procedure THelpaMainForm.Button1Click(Sender: TObject);
  HInst                             : THandle;
  FPointer                          : TFarProc;
  MyProc                            : Proc;
  DLLLoad                           : boolean;

  if HInst > 32 then
    FPointer := GetProcAddress(HInst,'CreateTemp');
    if FPointer <> nil then
      MyProc := Proc(FPointer);
      DLLLoad := true;

Code to Create form in DLL

Procedure CreateTemp;
  Screen.Cursor := crHourglass;
  Form1 := TForm1.Create( application );
  Screen.Cursor := crDefault;


Code used to Trap Exception in DLL

procedure TForm1.Button1Click(Sender: TObject);
  TESTNUM : real;

    TESTNUM := strtofloat(edit1.text) /                strtofloat(edit2.text);
    on EZeroDivide do
      MessageDlg('An exception occured!!',mtERROR, [mbOK], 0);

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Are you sure it is only the divide by zero that you can't trap? Try explicitly raising a EZeroDivide or an ESomething, and then catch them.


boabyteAuthor Commented:
All other excpetions can be trapped.
Recently I read about this...I would have been stumped for awhile too.  But now...this one is  almost EASY!  There is one IFFY part...but I'll get to that.

In your Button1Click procedure, I believe your exception is not being thrown because the compiler is optimzing the entire TESTNUM variable away.  It is not being used for anything useful in the procedure, therefore Delphi decides that it isn't needed and optimizes it away.

The IFFY part is the fact that you have a MessageDlg in the except part of the code...would Delphi optimize that away? I'm not sure.  But my thoughts are that it would.  Since MessageDlg is not actually altering any variables in your code, Delphi again views it as garbage code and optimizes it away.

There's your answer.  Make TESTNUM do something useful...perhaps assign it value to a global (after the try..except), then the code will not be optimized away.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

boabyteAuthor Commented:
Unfortunately, this is not the case.  The code supplied is
stripped down to a bare minimum.  The real code uses many floating point type variables and also the expcept part of the
procedure is a little more complicated than just calling a message dialog.  Also any other exception can be trapped (e.g. EDivByZero and various others) I have increased the points for
the question hoping that it could be answered.  If any more info
is required,
just ask.
In a/b, have you tried explicitly setting b=0??

With floating point

       b = (1.2345 - 0.1234)
       b = b - 1.1111
may not always yield b=0.  The numbers I've supplied are made
up, but you probably get the point.

I'm sure you have tried explicitly setting b=0, but I want to
make sure.
boabyteAuthor Commented:
Yes, I have tried explicitly setting b=0.
The problem is not that the DLL skips the exception,
but the Windows Operating system produces its own error screen
and completely crashes my program.
It could very well be the fact that you are calling the exception from code that belongs to this dynamic form you are creating in the DLL.

Will the DLL properly catch your EZeroDivide exception if it not a part of this dynamic form?

Your problem could stem from an inproperly created form within the DLL.  See if you can catch the exception in the manner that you'd like with a DLL call that has nothing to do with the dynamic form.  If everything is all right at that point, then I'd suspect that the dynamic form is the 'real' culprit.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.