Object reference not set to an instance of an object

[Danny]

Hi!

I have a really annoying problem. It's from a program I've done in Delphi 5
but now tries to get it working in Delphi 8. I have reproduced the problem
in the following extremly simple program, it has something to do with the
StretchDraw routine. When i run the program and execute the event
(formclick) an error occours:

"Object reference not set to an instance of an object"

Anyone have any ideas what to do. I have spent many hours on the internet
trying to solve that problem, this is my last chance except installing
Delphi 5 again.


Thanks

Daniel





------- The source code for the program that reproduces the error ------



unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ExtCtrls;

type
TForm1 = class(TForm)
procedure FormClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

{$R *.nfm}

procedure TForm1.FormClick(Sender: TObject);

var n:integer;
bild:TPicture;

begin
bild.LoadFromFile('c:\testbild.jpg');
Form1.Canvas.StretchDraw(TRect.Create(1,1,100,150), bild.Graphic);
bild.Free;
end;

end.

[Jamie]

Post by Danny
Hi!
I have a really annoying problem. It's from a program I've done in Delphi 5
but now tries to get it working in Delphi 8. I have reproduced the problem
in the following extremly simple program, it has something to do with the
StretchDraw routine. When i run the program and execute the event
"Object reference not set to an instance of an object"
Anyone have any ideas what to do. I have spent many hours on the internet
trying to solve that problem, this is my last chance except installing
Delphi 5 again.
Thanks
Daniel
------- The source code for the program that reproduces the error ------
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ExtCtrls;
type
TForm1 = class(TForm)
procedure FormClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.nfm}
procedure TForm1.FormClick(Sender: TObject);
var n:integer;
bild:TPicture;
begin
bild.LoadFromFile('c:\testbild.jpg');
Form1.Canvas.StretchDraw(TRect.Create(1,1,100,150), bild.Graphic);
bild.Free;
end;
end.

how about creating the object first before using it.
i really don't know how that could have worked in D5.
bild := TPicture.Create;

[Raptor]

Post by Jamie

Post by Danny
Hi!
I have a really annoying problem. It's from a program I've done in Delphi 5
but now tries to get it working in Delphi 8. I have reproduced the problem
in the following extremly simple program, it has something to do with the
StretchDraw routine. When i run the program and execute the event
"Object reference not set to an instance of an object"
Anyone have any ideas what to do. I have spent many hours on the internet
trying to solve that problem, this is my last chance except installing
Delphi 5 again.
Thanks
Daniel
------- The source code for the program that reproduces the error ------
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ExtCtrls;
type
TForm1 = class(TForm)
procedure FormClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.nfm}
procedure TForm1.FormClick(Sender: TObject);
var n:integer;
bild:TPicture;
begin
bild.LoadFromFile('c:\testbild.jpg');
Form1.Canvas.StretchDraw(TRect.Create(1,1,100,150), bild.Graphic);
bild.Free;
end;
end.

how about creating the object first before using it.
i really don't know how that could have worked in D5.
bild := TPicture.Create;

I think that's right. He's freeing an object he's never actually created.

BTW, bild.create will compile, IIRC, but will blow up when executed.

bild := TPicture.Create; is the syntax which works.

Raptor

[Danny]

Hi!

Well... that works!!!!!! ...frustrating, I have tried some things, but not
that, I'm not so used to freeing things and so on... :) ...but... now I can
go on with my nice project... Thanks!!!!

/Daniel

Post by Raptor

Post by Jamie
how about creating the object first before using it.
i really don't know how that could have worked in D5.
bild := TPicture.Create;

I think that's right. He's freeing an object he's never actually created.
BTW, bild.create will compile, IIRC, but will blow up when executed.
bild := TPicture.Create; is the syntax which works.
Raptor

[AlanGLLoyd]

Post by Raptor
BTW, bild.create will compile, IIRC, but will blow up when executed.
bild := TPicture.Create; is the syntax which works.
Raptor

Why it Does Not Work - detailed description

You must create a Delphi object by calling a _Class_ method (TPicture,Create),
not an instance method (Bild.Create). The class method returns a reference to a
newly created object for which memory has been allocated _and_ that memory has
been initialised to the new object. If you call a method of an instance
(Bild.Create) then no memory is allocated but initialisation of thet existing
object(Bild) is carried out. Of course if Bild has not yet been created by a
Class method then attempting to access Bild's memory to initialise it will
cause an access violation because there is NO memory allocated to Bild.

Alan Lloyd
***@aol.com

[Danny]

I'm sorry to bother you again. But now I have implemented the code in my
actual project, and it doesn't work. It seems to be another problem now. But
the same error dialog appears. I have tried some different things and the
problem seems to be in the picture loading or something. I have now put the
whole code from my actual project into this testprogram, I can't understand
what's causing the problem, I might try some other way of printing the
pictures.




unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, System.ComponentModel, Printers;

type
TForm1 = class(TForm)
PrintDialog1: TPrintDialog;
procedure FormClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

{$R *.nfm}

procedure TForm1.FormClick(Sender: TObject);

var cw, // canvas.width
ch, // canvas.height
rx, // räknare för kolumn (x-axel)
ry, // räknare för rad (y-axel)
b, // bildnummer
p, // sidnummer
x1,x2,y1,y2 // bildens koordinater
:integer;
bild: TBitmap;
namn: String;

begin

PrintDialog1.Execute;

With Printer Do Begin

Title:=('Utskrift');

cw := PageWidth;
ch := PageHeight;

rx:=1;
ry:=1;

p:=1;

BeginDoc;

Canvas.Brush.Style:=bsClear;
Canvas.Font.Height:=Round(ch/50);
Canvas.Font.Color:=clBlack;
Canvas.TextOut(Round(cw/20),Round(ch/40),'Testskolan, testklass');
Canvas.Font.Height:=Round(ch/90);

For b:=0 To 10 Do Begin

bild := TBitmap.Create;

bild.LoadFromFile('c:\testport.jpg');

namn := 'testnamn';

x1 := Round( cw/20 + (cw/5.3*(rx-1)) );
x2 := Round( x1 + (cw/6.7) );
y1 := Round( ch/15 + (ch/5.5*(ry-1)) );
y2 := Round( y1 + ((x2-x1)*1.25) );

Canvas.StretchDraw(TRect.Create(x1,y1,x2,y2),bild);
Canvas.Rectangle(TRect.Create(x1,y1,x2,y2));

bild.Free;

If Length(namn)<24 Then
Canvas.TextOut(x1, Round(y1+(ch/7.3)), namn)
Else Begin
If Length(namn)>48 Then Delete(namn,49,length(namn));
Canvas.TextOut(x1, Round(y1+(ch/7.10)), Copy(namn,0,24));
Canvas.TextOut(x1, Round(y1+(ch/6.45)),
Copy(namn,25,Length(namn)));
End;

If rx=5 Then Begin
Inc(ry);
rx:=1;
End Else Inc(rx);

If ry=6 Then Begin
Canvas.Font.Height:=Round(ch/80);
Canvas.Textout(Round(cw-(cw/11.4)), Round(ch-(ch/27)), 'Sida
'+IntToStr(p));
Printer.NewPage;
Inc(p);
Canvas.Textout(Round(cw-(cw/11.4)), Round(ch-(ch/27)), 'Sida
'+IntToStr(p));
ry:=1;
Canvas.Font.Height:=Round(ch/90);
End;
End;

EndDoc;

End;




end;

end.

[a***@aol.com]

You code ...

Canvas.StretchDraw(TRect.Create(x1,y1,x2,y2),bild);

However D3 Delphi Help on TPicture says that one should use the Graphic
property of a TPicture when calling StretchDraw (ie use Bild.Graphic).
Have you tried that.

Also I find it is better to use the loop variable when positioning
items in a loop. Use

LoopVar div CountPerRow

... for the row number and ...

LoopVar mod CountPerRow

... for the column number. Saves all thai Inc() etc. Position is then
Margin + (ColOrRowNo * Spacing).

Your code would be clearer without"magic numbers". ie numbers that you
don't say what they are. Defining a const has no effect on execution
speed and is easily read. Even if it did the effect is neglible.:
Alan Lloyd

[Danny]

Hello

Post by a***@aol.com
However D3 Delphi Help on TPicture says that one should use the Graphic
property of a TPicture when calling StretchDraw (ie use Bild.Graphic).
Have you tried that.

Yes I have. I have tried TPicture, TBitmap, TImage and the different ways to
get it to work, otherwise the compiler complains about uncompatible types.
In my code now I use TPicture.graphic.

Post by a***@aol.com
Also I find it is better to use the loop variable when positioning
items in a loop. Use

Aha... hmm... I'll take a look at them. I guess you must have ment the rx
and ry integers I had, that are kinda like x and y position variables.

Post by a***@aol.com
Your code would be clearer without"magic numbers". ie numbers that you
don't say what they are. Defining a const has no effect on execution

"Magic numbers"... hehe... yes, I guess outside people could find it
confusing, but they are only correction factors for just the expression that
they are in (it's rare that I use one many times). I have many of those, and
defining them as constants would just make it worse. Now I know exactly what
it's for when I look what the whole expression does, like positioning an
item on the canvas depending on the document width. I prefer doing nice code
with separators, grouping the loops and put some comments here and there.
The variable names are just used when building the structure, but once the
structure is made, I make the whole structure understandable. It works best
for me.


Anyway... I have made progress on my program now and my boss i happy about
it. So it's just to keep rockin'.

Thanks for the comments, it's always nice to see.


/Daniel

[Raptor]

Post by AlanGLLoyd

Post by Raptor
BTW, bild.create will compile, IIRC, but will blow up when executed.
bild := TPicture.Create; is the syntax which works.
Raptor

Why it Does Not Work - detailed description
You must create a Delphi object by calling a _Class_ method

(TPicture,Create),

Post by AlanGLLoyd
not an instance method (Bild.Create). The class method returns a reference to a
newly created object for which memory has been allocated _and_ that memory has
been initialised to the new object. If you call a method of an instance
(Bild.Create) then no memory is allocated but initialisation of thet existing
object(Bild) is carried out. Of course if Bild has not yet been created by a
Class method then attempting to access Bild's memory to initialise it will
cause an access violation because there is NO memory allocated to Bild.

Thanks. Eventually this stuff will sink in, I think, put various ways.

I wonder why the compiler couldn't handle the TPicture object the same way
it handled the integer.


var n : integer;
bild: TPicture;

In this case, the integer required no further intervention, like

n := TInteger.create; nor did it require

n.Free;

as did the TPicture declaration.


Raptor

[Danny]

Yes... it's a little strange, maybe because a TPicture is a complex object
compared to the integer which is just a number, not even a floating one...
:) ...but, if you use like thousands of integer variables, then it must be
some way of freeing the mem they use... hmm...

I thought of that and many other things while I was sitting on the toilet
before... :) ...it would be nice to know a whole lot of programming. I
started in DOS, and only now the basic things. But... I'll leave the more
advanced things to people that needs, and can handle them... :)

Sorry... I'm tired now after sitting here with my program. I'll guess your'e
not so interested in the philosophic aspects... :)

But... if I stick to my thread. Now I have downgraded my Delphi, and it
works without problems!!!! ...Delphi 8 had so much other things like .Net
and everything, not strange that my old program didn't work :) ...and Delphi
8 compiled an almost three times bigger executable of my program! :)

Well... those where the days... :)


Good night! Time to sleep

Post by Raptor
I wonder why the compiler couldn't handle the TPicture object the same way
it handled the integer.
var n : integer;
bild: TPicture;
In this case, the integer required no further intervention, like
n := TInteger.create; nor did it require
n.Free;
as did the TPicture declaration.

[Rob Kennedy]

Post by Raptor
Thanks. Eventually this stuff will sink in, I think, put various ways.
I wonder why the compiler couldn't handle the TPicture object the same way
it handled the integer.
var n : integer;
bild: TPicture;
In this case, the integer required no further intervention, like
n := TInteger.create; nor did it require
n.Free;
as did the TPicture declaration.

Well, for starters, Integer isn't a class, so you can't create it.

Second, how should the compiler know you _want_ a new TPicture instance?
Maybe you'll be using the variable to hold a reference to an object you
already got from somewhere else. Maybe your use of the variable will
depend on other factors in the code (reference an existing object if
there is one, else create a new one).

In a way, the compiler handled the TPicture variable is exactly the same
way it handled the Integer variable. The Integer was given its default
value, 0, and the TPicture reference was given its default value, nil.
The .Net managed code system requires those default values.

[Raptor]

Post by Rob Kennedy

Post by Raptor
Thanks. Eventually this stuff will sink in, I think, put various ways.
I wonder why the compiler couldn't handle the TPicture object the same way
it handled the integer.
var n : integer;
bild: TPicture;
In this case, the integer required no further intervention, like
n := TInteger.create; nor did it require
n.Free;
as did the TPicture declaration.

Well, for starters, Integer isn't a class, so you can't create it.
Second, how should the compiler know you _want_ a new TPicture instance?

var
oneInstance : TObject;
newInstance: TObject;

Why should this be an different than how the compiler knows I want another
integer?

If you mean at RUNTIME... see below.

Post by Rob Kennedy
Maybe you'll be using the variable to hold a reference to an object you
already got from somewhere else. Maybe your use of the variable will
depend on other factors in the code (reference an existing object if
there is one, else create a new one).

If I wished to do that with strings, i.e., create a new one, I'd create an
array of strings then resize the array and use the new string. Wouldn't that
work for objects?

Post by Rob Kennedy
In a way, the compiler handled the TPicture variable is exactly the same
way it handled the Integer variable. The Integer was given its default
value, 0, and the TPicture reference was given its default value, nil.
The .Net managed code system requires those default values.

The difference, of course, is that the integer, once declared as a variable,
is usable without saying

n := TInteger. Create

while the object is not. They would be alike if one could:

var
aInt : integer;
aLbl :TLabel;
begin
aInt := 1;
aLbl.caption := 'foofoo';

I'm wondering why this couldn't be done instead of the create-free business.
My uneducated wet-finger-in-the-wind guess, just for fun, is that it could,
but there'd likely be tradeoffs.

Raptor

[Rob Kennedy]

Post by Raptor
var
oneInstance : TObject;
newInstance: TObject;
Why should this be an different than how the compiler knows I want another
integer?

When you say "X: Integer" you're declaring an Integer variable. When you
say "Y: TObject" you're declaring a reference to an instance of TObject.
Whether you want to also create a new instance of that class has not
been stated. You might want to use that variable to refer to an instance
that you already created somewhere else. The compiler can't know what
you're going to use it for.

The Y TObject variable is just a reference to an object. The actual
memory occupied by the object does not reside in the memory represented
by Y. Instead, Y is just a four-byte reference -- a pointer -- to the
memory of the TObject instance. You can have multiple variables, all
refering to the same TObject instance.

Post by Raptor
If you mean at RUNTIME... see below.

Is there any other time?

Post by Raptor

Post by Rob Kennedy
Maybe you'll be using the variable to hold a reference to an object you
already got from somewhere else. Maybe your use of the variable will
depend on other factors in the code (reference an existing object if
there is one, else create a new one).

If I wished to do that with strings, i.e., create a new one, I'd create an
array of strings then resize the array and use the new string. Wouldn't that
work for objects?

In the Win32 personality of Delphi, that new string is actually a nil
pointer. There is no difference between an empty string and a nil
pointer. (You can construct an actual string of length 0, but it's
tricky.) Since the empty string is nil, there isn't really anything to
create. The same goes for other compiler-managed types, like WideString,
Variant, interface references, and dynamic-array references. All of them
start out life as all-bits-zero. When the compiler assigns a default
value to an object reference it gets all-bits-zero, too. That behavior
isn't spelled out for new elements of dynamic arrays, but I think that's
the way it works anyway.

In the .Net personality, a string is an object -- System.String descends
from System.Object. Treating the array's new string as a string works as
usual, but treating it as an object gives you a null-reference
exception. I'm not sure what the rules are for strings in .Net.

Post by Raptor

Post by Rob Kennedy
In a way, the compiler handled the TPicture variable is exactly the same
way it handled the Integer variable. The Integer was given its default
value, 0, and the TPicture reference was given its default value, nil.
The .Net managed code system requires those default values.

The difference, of course, is that the integer, once declared as a variable,
is usable without saying
n := TInteger. Create
var
aInt : integer;
aLbl :TLabel;
begin
aInt := 1;
aLbl.caption := 'foofoo';

*Which* label's caption? The compiler would need to create one
automatically. It would need to allocate the memory to hold an instance
of TLabel. But now suppose we don't really want a new label. Instead, we
want to iterate over the labels already in the form, and we need a
temporary variable to hold a reference to each successive label. The
compiler has already created a new TLabel that we don't want. What do we
do with it? Discard it, I suppose; .Net's garbage collector will recover
the wasted memory eventually.

Also, which constructor should the compiler call when automatically
instanciating the TLabel for us? TLabel.Create? Or
TLabel.CreateParented? Even if it can choose a constructor, what
parameters should it pass?

If we declare a TObject variable, how does the compiler know that we
want to store a TObject rather than holding some other type of object.
We might want to use it to refer to a TFont. The compiler can't know
that it should instanciate a TFont instead of a TObject. Worse yet, if
we declare a TStrings variable, does the compiler know that it can't
really create an instance of TStrings since it has abstract methods?
Should the compiler create a TStringList instead? Or maybe a
TListBoxStrings object.

[Raptor]

Post by Rob Kennedy

Post by Raptor
var
aInt : integer;
aLbl :TLabel;
begin
aInt := 1;
aLbl.caption := 'foofoo';

*Which* label's caption?

One could ask the same question about "which integer's value"? Or which
string's value.

Post by Rob Kennedy
The compiler would need to create one
automatically. It would need to allocate the memory to hold an instance
of TLabel.

Is that a problem? Presumably when I declare

var
aInt: integer;
aStr: string;

the compiler creates a PLACE where these can exist. The compiler doesn't
know what will be in the string, but it knows where 'foofoo' will go when we
subsequently say aStr := 'foofoo'. We did not need to explicitly tell the
compiler to save space for six bytes, at least not THIS compiler.

For that matter, isn't it the case that some compilers wouldn't even need us
to declare aStr: string;, that simply USING a string would be enough to tell
it to allocate a place for a string and assign it an initial value?

Post by Rob Kennedy
But now suppose we don't really want a new label. Instead, we
want to iterate over the labels already in the form, and we need a
temporary variable to hold a reference to each successive label. The
compiler has already created a new TLabel that we don't want. What do we
do with it? Discard it, I suppose; .Net's garbage collector will recover
the wasted memory eventually.

Makes sense.

Post by Rob Kennedy
Also, which constructor should the compiler call when automatically
instanciating the TLabel for us? TLabel.Create? Or
TLabel.CreateParented? Even if it can choose a constructor, what
parameters should it pass?

Are you saying that all OO compilers require us to both declare and then
create/free an object? Is that really inherent in OO compiler design?

Post by Rob Kennedy
If we declare a TObject variable, how does the compiler know that we
want to store a TObject rather than holding some other type of object.
We might want to use it to refer to a TFont. The compiler can't know
that it should instanciate a TFont instead of a TObject. Worse yet, if
we declare a TStrings variable, does the compiler know that it can't
really create an instance of TStrings since it has abstract methods?
Should the compiler create a TStringList instead? Or maybe a
TListBoxStrings object.

Are you saying that because OP requires (allows) us to both declare and the
create/free an object this allows us to do things we could not otherwise do?

If so, does this imply that the two are mutually exclusive, i.e., a compiler
which allowed us to simply declare and then use a TLabel in the way we
declare and then use a string, without create/free, would necessarily be
inflexible?

I'm hardly an expert on compiler design, but that would surprise me.

Raptor

[Maarten Wiltink]

[...]

Post by Raptor

Post by Rob Kennedy
Also, which constructor should the compiler call when automatically
instanciating the TLabel for us? TLabel.Create? Or
TLabel.CreateParented? Even if it can choose a constructor, what
parameters should it pass?

Are you saying that all OO compilers require us to both declare and then
create/free an object? Is that really inherent in OO compiler design?

No, but the alternative has _different_ problems.

C++ makes explicit the indirection in the model used by (among others)
Delphi and allows both of these:

1. TObject anObject;
2. TObject *anObject = new TObject();

The first is more like a record and, in a procedure, allocates memory
on the stack in which to place the object. In both cases, the act of
allocating memory triggers the constructor. Which constructor is called
depends on the parameters supplied; I don't know but I can imagine that
the first form does also allow supplying parameters.

Memory has to be allocated anyway; Delphi just doesn't allow the former
way. There are good reasons for that, too: it becomes a little too easy
to store object references all over the place that are left dangling
when the procedure returns. Oops. In C++, there are two kinds of objects
and they should be handled very differently, but the language doesn't
enforce it in any way.

Post by Raptor

Post by Rob Kennedy
If we declare a TObject variable, how does the compiler know that we
want to store a TObject rather than holding some other type of object.
We might want to use it to refer to a TFont. The compiler can't know
that it should instanciate a TFont instead of a TObject. Worse yet, if
we declare a TStrings variable, does the compiler know that it can't
really create an instance of TStrings since it has abstract methods?
Should the compiler create a TStringList instead? Or maybe a
TListBoxStrings object.

Are you saying that because OP requires (allows) us to both declare and
the create/free an object this allows us to do things we could not
otherwise do?

Yes. The entire concept of "aliases", references to objects owned by
other people, only comes into being when you can declare an object
reference without an object immediately springing into being. It also
makes polymorphism viable: using a TStringList _instance_ through a
TStrings _variable_. Note that this is the same as what Rob already
said.

Post by Raptor
If so, does this imply that the two are mutually exclusive, i.e., a
compiler which allowed us to simply declare and then use a TLabel in
the way we declare and then use a string, without create/free, would
necessarily be inflexible?

Nobody ever called C++ inflexible, I think. But if it did *not* allow
the second of those two forms above, that might have been different.

Delphi doesn't allow the first of those two forms above, yet it isn't
inflexible, either, because the remaining form can be made to do anything.
I don't think anybody has ever missed being able to allocate an object on
the stack. People _have_ complained about the resulting verbosity.

Groetjes,
Maarten Wiltink

[Raptor]

Post by Maarten Wiltink
Nobody ever called C++ inflexible, I think. But if it did *not* allow
the second of those two forms above, that might have been different.
Delphi doesn't allow the first of those two forms above, yet it isn't
inflexible, either, because the remaining form can be made to do anything.
I don't think anybody has ever missed being able to allocate an object on
the stack. People _have_ complained about the resulting verbosity.

Helpful explanation, Maarten.

R

[Jamie]

Post by Raptor
Are you saying that because OP requires (allows) us to both declare and the
create/free an object this allows us to do things we could not otherwise do?
If so, does this imply that the two are mutually exclusive, i.e., a compiler
which allowed us to simply declare and then use a TLabel in the way we
declare and then use a string, without create/free, would necessarily be
inflexible?
I'm hardly an expert on compiler design, but that would surprise me.
Raptor

nice thread subject.
many have forgotten the old OBJECT style where it was
static. i think i was told that D 2005 still supports it.
that style does not require to call Create if there
are no required initiated (dynamic types) that have to be
set up ahead of time.
so one could simply make a few objects (not Tobject) with
a few functions and procedures to process some data.
etc..
example.
Type
TMyType = object
private
findex:integer;
// functions etc.., just like the classes.

public
// properties etc...
End;
// some where in implementation land.

function TMyType.SomeFunction(..,.,.,):xxxx;
Beign
//code
End;

.....
one can use this any time with out using a call to a create
or destroy etc...
the only problem with this is if you were to use the dynamic
type strings that every one is so use to now, instead of the
short strings
in that case, there are 2 system procedures you can to initiate
the storage and unitiate the storage for the strings. these functions
are also called in the background for area's where the compiler does
know about dynamics strings being present in code or Records etc..

[Rob Kennedy]

Post by Jamie
many have forgotten the old OBJECT style where it was
static. i think i was told that D 2005 still supports it.

To my knowledge, no Win32 version of Delphi has really supported it. The
compiler will let you write code for it, but the generated code won't be
right.

The .Net versions definitely don't support it.

[Jamie]

Post by Rob Kennedy

Post by Jamie
many have forgotten the old OBJECT style where it was
static. i think i was told that D 2005 still supports it.

To my knowledge, no Win32 version of Delphi has really supported it. The
compiler will let you write code for it, but the generated code won't be
right.
The .Net versions definitely don't support it.

i use it in D3, and 7.
works fine. as long as you don't use the long strings
and system dynamic arrays. well i should say you can
use those, you simply need to call a couple of functions
to initiate and uninitiate then in the object.
other wise one could just simply use the short strings.
in any case, the code i use it for does not involve using
long strings and dynamic arrays so there isn't a problem.