boabyte
asked on
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.
Type
Proc = procedure;
procedure THelpaMainForm.Button1Clic k(Sender: TObject);
var
HInst : THandle;
FPointer : TFarProc;
MyProc : Proc;
DLLLoad : boolean;
begin
if HInst > 32 then
begin
FPointer := GetProcAddress(HInst,'Crea teTemp');
if FPointer <> nil then
begin
MyProc := Proc(FPointer);
MyProc;
DLLLoad := true;
end;
end;
end;
************************** ********** ********** ********** ****
Code to Create form in DLL
Procedure CreateTemp;
begin
Screen.Cursor := crHourglass;
Form1 := TForm1.Create( application );
Screen.Cursor := crDefault;
Form1.Show;
end;
************************** ********** ********** ********** ****
Code used to Trap Exception in DLL
procedure TForm1.Button1Click(Sender : TObject);
var
TESTNUM : real;
begin
try
TESTNUM := strtofloat(edit1.text) / strtofloat(edit2.text);
except
on EZeroDivide do
begin
MessageDlg('An exception occured!!',mtERROR, [mbOK], 0);
exit;
end;
end;
end;
************************** ********** ********** ********** ****
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.
Type
Proc = procedure;
procedure THelpaMainForm.Button1Clic
var
HInst : THandle;
FPointer : TFarProc;
MyProc : Proc;
DLLLoad : boolean;
begin
if HInst > 32 then
begin
FPointer := GetProcAddress(HInst,'Crea
if FPointer <> nil then
begin
MyProc := Proc(FPointer);
MyProc;
DLLLoad := true;
end;
end;
end;
**************************
Code to Create form in DLL
Procedure CreateTemp;
begin
Screen.Cursor := crHourglass;
Form1 := TForm1.Create( application );
Screen.Cursor := crDefault;
Form1.Show;
end;
**************************
Code used to Trap Exception in DLL
procedure TForm1.Button1Click(Sender
var
TESTNUM : real;
begin
try
TESTNUM := strtofloat(edit1.text) / strtofloat(edit2.text);
except
on EZeroDivide do
begin
MessageDlg('An exception occured!!',mtERROR, [mbOK], 0);
exit;
end;
end;
end;
**************************
ASKER
All other excpetions can be trapped.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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.
ASKER
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.
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.
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.
Erik.