You confirmed what I thought. From what I've been able to find out,
there are three ways to end the life of a dynamic array. The first is to
delete it's last element, ( I was calling them fields before...sorry ), in
which case Delphi will dispose of it because it's reference count goes to
zero. The second, by setting it to nil. And the third by setlength(array,
0). I really wish that my old copy of Memory Sleuth worked with D10 though
as that's how I used to check such things just to be sure. I've seen way
too many inconsistencies in the way TaskManager reports various allotments
to trust it!
I knew that an Array isn't a TComponent descendant but what struck
me as strange is that CodeInsight shows I can do this:
MyArrayofTComponents[0].Create() and asks for an Owner where the Array is
one of a set of TComponent. What is it attempting to create here? I
thought perhaps it was a shortcut to creating an element of the type but
though it compiles fine I get an AV as soon as I attempt to access one of
the element properties! Also I noticed in my last post I did confuse the
issue by interchanging TComponent and TObject. That was unintentional. I
originally planned to use either a TObject or a Record but then changed my
mind when I realized I could use a TComponent and solve a lot of problems
all at once.
The nice thing about using an array for something like this is the
fact you can directly access the element properties no matter if it is a
TComponent, a TObject, or a Record! You can't do that with a TList or any
of its derivatives.
Therefore, what I finally decided to do is create a descendant of
the TEdit class I wanted to use, ( the TMSAdvancedMemo component ), and add
a few properties and methods to it I needed. Then I can create everything I
need in one simple step without the need for any additional objects or
records. MyArrayofTMSEdits[0] := TtmsEdits.Create(aOwner);
My next step is to further reduce this down to a single component
which is a descendant of the TTabControl containing an array of the TEdit
type I need with the TabControl being set as the edits owner and with its
own counter and the additional methods needed to add and delete Tabs and
elements as required. Even then I probably won't need to add any methods as
the TabControl already has them to handle the Tabs. I can just override
them to include handling the edits as well! And this way I also won't have
to worry about freeing the Edits either!
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Cosmin Prund
Sent: Saturday, March 04, 2006 9:59 AM
To: 'Borland's Delphi Discussion List'
Subject: RE: Objects and Lists...addendum
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Robert Meek
> Sent: Saturday, March 04, 2006 1:00 PM
> To: 'Borland's Delphi Discussion List'
> Subject: RE: Objects and Lists...addendum
>
> In regards to the previous question below, some years ago when I
> first started learning Delphi, I had an interesting conversation with
> Cosmin
> right here about the various ways one could setup an editor for multiple
> pages/files.
Some years ago? Have I been a member for that long?
> So if I create an array is ii okay to set its length at the start to
> just 1? I tried it and it compiles and runs okay but I wondered if there
> might be something else that would make doing so a bad idea?
Nothing wrong with 1. You may set it up to whatever works for you.
> Now when I need to create a new page in the editor, I first create
> the new tab, then a new instance of the object type I wrote, and then I
> call
> SetLength and increment its current length to hold another object, and
> finally I assign the object to the array. All this I've tested and it
> works
> great but it's freeing the resources used I'm not so sure about.
> When I'm ready to close the editor, I must first free and nil each
> instance of my object that I had created at runtime, correct? But what if
> when I create each object I set the form as the object's owner? Would
> they
> then be freed like any other component when the form itself is freed?
I wasn't able to follow. What objects are you creating at runtime? The ones
that go into the array? Did you go for objects or records? If you did go for
records they can't be freed as they're not objects!
> What
> about making the object's owner the array itself? Is this possible and
> would there be any advantage or disadvantage to doing so? And finally, is
If by Object you mean TObject then you can't set it's owner because it
doesn't have one. It is the TComponent class that introduces. Alo
TComponent's owner must itself be an TComponent. Arrays are not TComponent
descendent so they can't be used as the owner for an TComponent descendent.
> And finally, is it true that no matter how many fields an array might
> contain, simply
> setting the array to nil will free it properly, or do I have to iterate
> thru
> and delete each field first? Is there anyway, like with an ObjectList, to
> make the array responsible for the objects it references?
When I need to "free" an array I usually do SetLength(array,0); I don't know
if this is equivalent to assigning it nil.
About making it responsable for it's content:
The array can't be smarten up. TObjectList can be made smart because it has
a destructor. The only smart thing the array would be to Dispose()
everything. This means you can safely have strings in the array as the
memory allocated for those would be freed. It will not free objects.
Everything I've sad is true for Win32 Delphi. Don't know enough about dot
net!
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
