I have an application that is crashing with 0x0eedfade exception.
This exception is reported in windows event logs, but is not caught by the applications exception handler. To better understand how this may be happening, I would like to create a test app which produces the same error.
The answer to this question here suggests it is caused by raising a Delphi exception across module boundaries. In light of this I created a Delphi library which throws an exception and a Delphi exe that calls the library.
Library code
library Project2;
uses
SysUtils,
Classes;
{$R *.RES}
procedure DllException; export;
begin
raise Exception.Create('Library exception');
end;
exports DllException;
begin
end.
Program code
unit test;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, ExtCtrls, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
private
procedure AppOnException(Sender: TObject; E: Exception);
public
end;
var
Form1: TForm1;
procedure DllException; external 'Project2.dll'
implementation
{$R *.DFM}
procedure TForm1.AppOnException(Sender: TObject; E: Exception);
begin
OutputDebugString(PChar(E.Message));
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
Application.OnException := AppOnException;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
DllException;
end;
end.
I was expecting this to produce a 0x0eedfade exception and the program to crash. What happens is an error message displays essentially saying "Library exception" and the program carries on.
How can I create a test application that produces a 0x0eedfade exception?
Related
I have a major problem and I have no idea how it might be corrected. Out of the blue, when I compile then try to run my application - which I have been working on for six months - I get a Class Not Registered error. I also have a pop-up error message saying that dbx.dbl was not found. I have added nothing to the program in the past few days which included any new classes. I am using Delphi 5. I do not know how to identify which class is not registered. The program will not run and I have spent hours trying to track down the problem without success.
More information: I have moved the executable and data files to another computer, and it all runs fine. So it seems to be a problem with my development box.
More Information: I did as fpiette suggested but found nothing which helped. So I created a very basic application:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, Db, ADODB;
type
TForm1 = class(TForm)
ADOConnection1: TADOConnection;
ADOQuery1: TADOQuery;
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
procedure TForm1.Button1Click(Sender: TObject);
begin
ADOConnection1.Connected := True;
ADOQuery1.Close;
ADOQuery1.Connection := ADOConnection1;
ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('select * from tblsupplier');
ADOQuery1.Open;
end;
end.
The Class Not Registered error occurs when it executes the ADOQuery1.Open; line.
Am I right in assuming that since there are no other components in the program that the error must be in the ADO code? The ADOConnection1 points at an Access database called Suppliers and the connection test was successful.
I've downloaded Delphi XE7 and having some problems with accessing another Units...
I need to call procedures from another units, so I'll give a very basic illustration, simple program...
This is code from main Unit1 with form and button1:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics,
Controls, Forms, Dialogs, StdCtrls, Unit2;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
ShowMessage('Hello');
end;
end.
And this is the code from Unit2:
unit Unit2;
interface
implementation
uses Unit1;
end.
Now, how is it possible to make procedure Button1Click like in Unit2 to showmessage let's say HelloFromUnit2 when button1 on form1 is clicked? Unit2 is codeUnit without anything..
Use the build in procedure for calling the Click handler
Leave form 1 the way it is:
unit Unit2;
interface
implementation
uses
Unit1;
procedure Click;
begin
if Assigned(Form1) then
Form1.Button1.Click;
end;
end.
Add a procedure declaration to the public section of TForm1, like this
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
Procedure SayHello;
end;
...
procedure TForm1.SayHello;
begin
ShowMessage('Hello');
end;
end.
Then in Unit2 you would call this procedure. You would have to ensure that Form2 has already been instantiated - or create a new instance for your call.
Do not use this mechanism for event handlers!
The header of your post doesn't match the question in the text
"Call Button1Click in Form1/Unit1 from Unit2" vs.
"Now, how is it possible to make procedure Button1Click like in Unit2 to showmessage let's say HelloFromUnit2 when button1 on form1 is clicked?"
I answer the question in the text (as I understand it). If this is not what you intended, you might want to rephrase the question in the text.
Add, to Form1.Button1Click, a call to a new procedure in unit2
procedure TForm1.Button1Click(Sender: TObject);
begin
ShowMessage('Hello');
SayHelloFromUnit2; // <---- add this
end;
In unit2 add the following to the interface section:
procedure SayHelloFromUnit2;
and to the implementation section
uses Vcl.Dialogs;
procedure SayHelloFromUnit2;
begin
ShowMessage('Hello from unit2');
end;
I have an object that is created on Form1 and I would like to be able to access one of its fields on Form2. I have tried to google it and nobody can give an answer that I can understand. Please excuse me but I am a novice.
Form1
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
Ttest=class
public
sName:string;
end;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
end;
var
Form1: TForm1;
implementation
uses Unit2;
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
myObj:Ttest;
begin
myObj.Create;
myObj.sName := 'Name';
Form2.Show;
end;
end.
Form2
unit Unit2;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm2 = class(TForm)
Button2: TButton;
procedure Button2Click(Sender: TObject);
end;
var
Form2: TForm2;
implementation
uses Unit1;
{$R *.dfm}
procedure TForm2.Button2Click(Sender: TObject);
begin
ShowMessage(myObj.sName);//This is not working
end;
end.
You have two forms that both use an object. You should define the object in a separate unit and list it in the Uses clause in the Interface section of both forms. Try using something already defined in a main library, like TStringlist, so you don't get confused with this part.
From what you're showing here, you're attempting to create an instance of that object in one form and do something with it in another form. That's a common thing to do: you may have one unit that asks for a filename and loads a file into a TStringList, then hands that over to another form or unit to deal with.
The way you're doing it, however, can be improved to reduce coupling between the two forms.
What you want to do is define a property like this in TForm2:
TForm2 = class( TForm )
. . .
private
Ftestobj : TTest; // or TStringlist
public
property testobj : TTest read Ftestobj write Ftestobj;
Then in TForm1.OnButtonClick do something like this:
form2.testobj := myobj;
form2.Show;
And then this becomes:
procedure TForm2.Button2Click(Sender: TObject);
begin
ShowMessage(Ftestobj.sName);
end;
I did a whole session in CodeRage 9 on this topic recently, in fact. It's entitled, "Have you embraced your inner plumber yet?" and it's all about moving data in and out of forms like this. (I call it plumbing code.)
Search for "coderage 9" and watch the video. At the end is a link where you can download my example code. That should keep you busy for a while. :)
There's something I keep running into that I really haven't solved with Delphi programs and was wondering if anyone could instruct me on it. As the topic says, how do you do proper catastrophic error handling? For instance:
// is file necessary for the program present?
if not FileExists(FilePath1) then
begin
raise Exception.Create(FilePath1 + ' does not exist and is required for this program to function.');
// I obviously need to do something here to make the program QUIT and not have
// any more code run.
Application.Terminate;
Abort;
end;
I can use the exception unit there as well and throw out an exception, but the program continues as before. I've used the halt call in the past, but it seems to not do any cleanup or the like so I end up making a big procedure with close and free calls for everything I've done just to be sure (and even then I'm not sure of any of the behind the scenes stuff).
So what is the right way to handle such things?
Edit: To clarify, I'm wanting to know about how to make the program do what clean-up it needs to do and then EXIT NOW and not do any other code.
To perform abnormal termination call Halt() passing the exit code.
if CatastropicErrorDetected then
begin
... show error message
Halt(1);
end;
On Windows this results in a call to TerminateProcess and will stop execution there and then.
You note that no cleanup is performed and usually that's what you want. Since you are performing this check at application startup there should be nothing to cleanup.
IMHO the only clean way would be checking for "Fatal conditions" before Application is running.
program Project2;
uses
Forms,Dialogs,
Unit1 in 'Unit1.pas' {Form1};
{$R *.res}
begin
ReportMemoryLeaksOnShutDown := true;
Application.Initialize;
if True then // your condition here
begin
MessageDLG('Fatal Error',mtError,[mbok],0);
end
else
begin
Application.CreateForm(TForm1, Form1);
Application.Run;
end;
end.
Any other approach will have side effects
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private-Deklarationen }
FSL:TStringList;
public
Destructor Destroy;override;
{ Public-Deklarationen }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
destructor TForm1.Destroy;
begin
FreeAndNil(FSL);
Showmessage('Will never be seen with Application.Terminate + HALT');
inherited;
end;
procedure TForm1.FormCreate(Sender: TObject);
const
Testing=0; // try 1 and 2 too
begin
FSL:=TStringList.Create;
Try
raise Exception.Create('Terminating now');
except
case Testing of
0: begin
// exception object will not be freed other code will be prevented, Form won't be shown
Application.Terminate;
HALT;
end;
1: begin
// exception object will not be freed Form won't be shown
HALT;
end;
2: begin
// clean but Form will be shown
Application.Terminate;
end;
end;
end;
end;
end.
You can instruct the application global object to terminate the program by calling Application.Terminate.
Call Terminate to end the application programmatically. By calling Terminate rather than freeing the application object, you allow the application to shut down in an orderly fashion.
Terminate calls the Windows API PostQuitMessage function to perform an orderly shutdown of the application. Terminate is not immediate.
Since the call can occur deeper in the stack, you can also raise an Exception, and you code your program to not handle it in order to let the execution reach the main application loop and the default exception handler catch it.
That way, you effectively prevent's more code to run in your application.
In code it may look like this:
if not FileExists(FilePath1) then
begin
MessageDlg(FilePath1 + ' does not exist and is required for this program to function.',
mtWarning, [mbOK], 0);
Application.Terminate;
Abort; //raising a EAbort just as an example
end;
Depending on where this code is called, I advise you not to show the message directly, but rather raise an exception with the message and let the application object default HandleException method show the message for you:
if not FileExists(FilePath1) then
begin
Application.Terminate;
raise EMyFatalException.Create(FilePath1
+ ' does not exist and is required for this program to function.');
end;
Which looks more natural to me. EMyFatalException is a hypothetical exception class you can declare and never handle in your except clauses.
You can write your own Application.OnException handler, ex:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
procedure HandleException(Sender: TObject; E: Exception);
end;
var
Form1: TForm1;
type
EMyFatalError = class(Exception);
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
Application.OnException:= HandleException;
raise EMyFatalError.Create('OOPS!');
end;
procedure TForm1.HandleException(Sender: TObject; E: Exception);
begin
Application.ShowException(E);
if E is EMyFatalError then
Application.Terminate;
end;
end.
I'm using old style Pascal I/O routines and expect that calls to I/O functions that fail should raise an EInOutError. When I try this I do not see an exception raised and I have no clue why.
procedure TForm1.Button1Click(Sender: TObject);
//var i: integer;
begin
id:=(strtoint(Edit1.Text)-1)*4;
AssignFile(plik,'\klienci\'+linia_klient[id]+'.txt');
try
Reset(plik);
except
on EInOutError do Rewrite(plik);
end;
edit2.Text:=linia_klient[id+1];
edit3.Text:=linia_klient[id+2];
//ListBox1.Clear;
//ListBox1.Items.Add();
end;
Entire code:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Label1: TLabel;
Edit1: TEdit;
Button1: TButton;
Label2: TLabel;
Label3: TLabel;
Edit2: TEdit;
Edit3: TEdit;
ListBox1: TListBox;
Label4: TLabel;
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
plik:TextFile;
linia_klient,linia_video:array[0..20] of string;
id:integer;
implementation
{$R *.dfm}
{$IOCHECKS ON}
procedure TForm1.FormCreate(Sender: TObject);
var i:integer;
begin
Edit1.Text:='Witaj, Podaj ID klienta';
Label1.Caption:='ID';
AssignFile(plik,'klienci.txt');
Reset(plik);
i:=0;
While Not Eof(plik) do
begin
Readln(plik,linia_klient[i]);
inc(i);
end;
CloseFile(plik);
AssignFile(plik,'video.txt');
Reset(plik);
i:=0;
While Not Eof(plik) do
begin
Readln(plik,linia_video[i]);
inc(i);
end;
CloseFile(plik);
end;
procedure TForm1.Button1Click(Sender: TObject);
//var i: integer;
begin
id:=(strtoint(Edit1.Text)-1)*4;
AssignFile(plik,'\klienci\'+linia_klient[id]+'.txt');
try
Reset(plik);
except
on EInOutError do Rewrite(plik);
end;
edit2.Text:=linia_klient[id+1];
edit3.Text:=linia_klient[id+2];
//ListBox1.Clear;
//ListBox1.Items.Add();
end;
end.
The exception EInOutError will only be raised if I/O checking is enabled. To make sure it is enabled do the following:
In your project options, in "Delphi Compiler Options" check the checkbox I/O checking
Remove any {$IOCHECKS OFF} or {$I-} directives from your code as they disable I/O checking
This should give you a proper exception if the file doesn't exist.
Now if (for whatever reason) you cannot enable I/O checking:
With disabled I/O checking you won't get an EInOutError if something goes wrong. Instead you have to check the value of IOResult after every I/O operation. It's like in old Pascal times: If IOResult <> 0 then an error happened.
This (slightly adapted) excerpt from the Delphi docs shows how to work with IOResult:
AssignFile(F, FileName);
{$I-}
Reset(F);
{$I+}
if IOResult = 0 then
begin
MessageDlg('File size in bytes: ' + IntToStr(FileSize(F)),
mtInformation, [mbOk], 0);
CloseFile(F);
end
else
MessageDlg('File access error', mtWarning, [mbOk], 0);
However, nowadays you should use TFileStream to access/create files and don't use the old style Pascal routines anymore. An example how this could look:
filename := '\klienci\'+linia_klient[id]+'.txt';
if not FileExists(filename) then
// "Create a file with the given name. If a file with the given name exists, open the file in write mode."
fs := TFileStream.Create(filename, fmCreate) else
// "Open the file to modify the current contents rather than replace them."
fs := TFileStream.Create(filename, fmOpenReadWrite);
I interpret your question that you would like EInOutError exceptions to be raised whenever a Pascal style I/O function fails. In order to do this you need to enable the I/O checking compiler option.
I/O checking: Enables or disables the automatic code generation that checks the result of a call to an I/O procedure. If an I/O procedure returns a nonzero I/O result when this switch is on, an EInOutError exception is raised (or the program is terminated if exception handling is not enabled). When this switch is off, you must check for I/O errors by calling IOResult.
I guess the code you are working with was written under the assumption that the I/O checking option was enabled, but that you are compiling with it not enabled. Here's a bit of code that demonstrates EInOutError being raised due to an I/O error.
program IOchecking;
{$APPTYPE CONSOLE}
{$IOCHECKS ON}
uses
SysUtils;
var
F: File;
begin
AssignFile(F, 'path/to/file/that/does/not/exist');
Reset(F);//raises EInOutError
end.
I strongly recommend that you enable I/O checking. This will allow you to handle errors using exceptions in a manner consistent with the rest of your code.
Not using I/O checking forces you to check the value of IOResult after every I/O function. This is very error prone (it's easy to forget to check) and results in untidy code.
If you are already running with I/O checking enabled then the most likely explanation for you not seeing an error is that in fact no error is occurring. Perhaps the file does in fact exist.