How to clear a Collection?
Jim Elden
Collection.Remove in a loop? Is there a more elegant way?
Thanks!
Jim
adlerfam
objects in the collection are being referenced externally.
Good luck.
"Jim Elden" <x@yz> wrote in message
news:#smtR2HA...@cppssbbsa02.microsoft.com...
Frank Oquendo
--
Attitudes are contagious. Is yours worth catching?
http://www.acadx.com
Steven A. Mitchell
adlerfam wrote in message ...
>Collection.Clear will clear the whole collection, as long as none of the
>objects in the collection are being referenced externally.
>
In the standard VB collection, there is no "Clear". To safely partially
clear a collection, it's a good idea to remove the items in reverse order to
keep the indexes straight. Of course, for a complete clear this isn't
necessary, and it can be done like this:
Private m_col As Collection
...
Public Sub Clear()
Do While m_col.Count > 0
m_col.Remove 1
Loop
End Sub
Error handling is removed for brevity. When I wrap the VB collection, I
nearly always add the Clear method and implement it that way. I haven't
down performance testing to see if an iteration using For..Next or For..Each
will work better in some or all circumstances. The above has worked fine
for me.
Steven
Larry Serflaten
How about
Set MyCollection = Nothing
For those ocassions where there is nothing holding a reference
to objects in the collection, the above works well...
LFS
Grinder
> to objects in the collection, the above works well...
>
liability in doing this?
For example, if I have a Table object that contains a collection of Field
objects, can't I reasonably use another contained collection of Field
objects (from the first collection) to define my primary keys? If I drop a
field from my key do I incur some risk because there is a remaining
reference to that Field in my fields collection?
Jeff Ashley
> Private m_col As Collection
> ...
> Public Sub Clear()
> Do While m_col.Count > 0
> m_col.Remove 1
> Loop
> End Sub
I'm lost. What does this accomplish that
Set mcol = new collection
doesn't?
Larry Serflaten
Can you put that in code? The text version seems a bit confusing.
LFS
"Grinder" <no....@no.spam.spam.spam.net> wrote in message news:EaKj5.13229$SM4.1...@nntp2.onemain.com...
bob butler
Jeff Ashley <jeffa...@worldnet.att.net> wrote in message
news:398F8638...@worldnet.att.net...
It makes a difference if you have multiple references:
Set m_Col=New Collection
m_Col.Add "something"
Set m_Col2=m_Col
Call Clear ' both m_Col and m_Col2 still point to the same (empty)
collection
set m_col=New Collection ' m_col is new, m_col2 still holds "something"
Steven A. Mitchell
bob butler wrote in message <#t$5A4TAAHA.292@cppssbbsa05>...
>It makes a difference if you have multiple references:
>
>Set m_Col=New Collection
>m_Col.Add "something"
>Set m_Col2=m_Col
>
>Call Clear ' both m_Col and m_Col2 still point to the same (empty)
>collection
>
>set m_col=New Collection ' m_col is new, m_col2 still holds "something"
Right--that's the main difference. It also matters if the collection hangs
onto other objects that may be fairly heavy to allocate. If there are not
very many items in such a collection, dropping the whole mess can be a major
performance hit even compared to my simple routine. I had a bunch of
collection like that at one time--I doubt it is a very common occurance.
Though that makes me realize that setting to a new collection probably
*would* work in my case. The Clear method is implemented on my wrapper for
the collection. That means the only references to "m_col" for a given
collection are within the wrapper object. So even if clients have a 100
references to the wrapper, the Clear could still set to a new Collection,
and it would work for every reference.
You would need the wrapper and the Clear implementation to take advantage of
that situation, but it certainly would simplify (and probably speed up) the
Clear implementation.
Steven
Steven A. Mitchell
Grinder wrote in message ...
>For example, if I have a Table object that contains a collection of Field
>objects, can't I reasonably use another contained collection of Field
>objects (from the first collection) to define my primary keys? If I drop a
>field from my key do I incur some risk because there is a remaining
>reference to that Field in my fields collection?
Only if you were expecting the two references to point to the *same*
collection.
Steven
Jeff Ashley
You're absolutely right! I don't know that I have often been in the
circumstance of maintaining two references to the same collection for
any length of time, but you have pointed out how aware one must stay . .
. BTW, this is also relevant to the matter of passing objects to a
function byval or byref: if byref, the reference itself is sent and
setting the object to a new object clears the 'original', but this Clear
method would be the only way to clear it if the pass is byval . . .
bob butler wrote:
>
> Jeff Ashley <jeffa...@worldnet.att.net> wrote in message
> news:398F8638...@worldnet.att.net...
> > Steve:
> >
> > > Private m_col As Collection
> > > ...
> > > Public Sub Clear()
> > > Do While m_col.Count > 0
> > > m_col.Remove 1
> > > Loop
> > > End Sub
> >
> > I'm lost. What does this accomplish that
> >
> > Set mcol = new collection
> >
> > doesn't?
>
Grinder
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:ukTRQASAAHA.295@cppssbbsa05...
>
> Can you put that in code? The text version seems a bit confusing.
Sure, it would look something like this: (Please note that this is
illustrative code only.)
Option Explicit
Option Compare Text
Private mcFields As Collection
Private mcPrimaryKey as Collection
Public Sub DefinePrimaryKey(ParamArray sField() As Variant)
Dim oField As Field
Dim iField as Long
'this is would be an occassion where something (mcFields) is
'holding a reference to objects in the collection...
Set mcPrimaryKey = New Collection
For iField = Lbound(sField) to Ubound(sField)
Set oField = mcFields.Item(sField(iField))
mcPrimaryKeys.Add oField, oField.Name
Next iField
End Sub
>
> LFS
>
> "Grinder" <no....@no.spam.spam.spam.net> wrote in message
news:EaKj5.13229$SM4.1...@nntp2.onemain.com...
> > > For those ocassions where there is nothing holding a reference
> > > to objects in the collection, the above works well...
> > >
> > I've seen this remarked a couple of times in this thread. What is the
> > liability in doing this?
> >
Grinder
collection, what risks does that pose. Excluding, of course, the obvious
difficulties presented by casually handing out references to "contained"
objects.
"Steven A. Mitchell" <sami...@ingr.com> wrote in message
news:#FsvTWUA...@cppssbbsa02.microsoft.com...
>
>
> Grinder wrote in message ...
> >For example, if I have a Table object that contains a collection of Field
> >objects, can't I reasonably use another contained collection of Field
> >objects (from the first collection) to define my primary keys? If I drop
a
> >field from my key do I incur some risk because there is a remaining
> >reference to that Field in my fields collection?
>
Steven A. Mitchell
Grinder wrote in message ...
>The original warnings were cautious about references to objects IN the
>collection, what risks does that pose. Excluding, of course, the obvious
>difficulties presented by casually handing out references to "contained"
>objects.
No risk, other than the usual issues of having multiple references to the
same objects. The point was that setting a collection to Nothing is not
always the same as calling a Clear method. Really, this is true of any
container. For some reason, even people that know better (myself included)
get all gooey eyed about the power of "Set obj To Nothing" on class
hierarchies--unless we work to keep our heads screwed on straight <grin>.
Steven