Collection Mystery 1

[NeilFrank]

I am encountering a bizarre (at least to me) problem using a Collection, which I’ll call gcollFoo, when working within an MDI/child environment in VB6. <br>
<br>
I declare and create gcollFoo as a global object in the Code Module. <br>
<br>
When gcollFoo is populated (with a series of string variables, each without a key) within the MDI Main window, problems arise when I attempt to access it in child window ‘A’. When I try to read any one of gcollFoo’s members, eg with the statement strMem = gcollFoo(integer), VB6 crashes with the error message 'either BOF or EOF is true or the current record has been deleted; the operation requires a current record.’ Yet, gcollFoo is intact prior to the crash, as demonstrated by the fact that its .Count Property and .Remove Method work properly!<br>
<br>
Furthermore, when gcollFoo is populated in child window ‘B’ (ie and not in MDI Main) then the very same code in child window ‘A’ can loop through and read its members without a hitch!!<br>
<br>
I have tried late binding, ie declaring gcollFoo in the Code Module and creating it in MDI Main, but this does not help. Also, adding a key to each member gets me nowhere.<br>
<br>
I would also note that in a much simpler MDI test program I wrote, where I do (it would seem) the exactly analogous operations, I encounter no problems, thus demonstrating that it is legal to fill a global Collection in MDI main and read it in a child window. <br>
<br>
Any thoughts on the matter are greatly appreciated!<br>
<br>
TIA<br>
<br>
/Frank<br>
<br>

 

[PeteJS]

What about declaring the collection as PUBLIC and declare it in a module?

 

[mrblurgle]

Not a solution, but a similar problem with collections ...
I have a VB6 app on XP which also happens to be using MDI forms (I don't know if this matters).

I have declared a collection at form Module level and then destroy and recreate it as necessary. I add some (or one) items using a key, then check the count the I try and access the item(s) using the ordinal index and VB dies a horrible death. It is VB itself reporting an error, not a trappable error within my program.

This was working OK, then started dying occasionally and now seems to die every time.

I have considered, but haven't yet tried:
- Using a dictionary instead of a Collection
- Wrapping it up in a class
- Emptying the collection instead of destroying it
- Changing the scope of the collection

Keith.

 

[NeilFrank]

Thanks for the response Keith . . . to a question I posted 2 years ago !!!!!

I have subsequently figured out the cause of my woes, but having forgotten I had asked the question I never thought to share this knowledge.

It turns out that I had been adding a reference to a recordset to my collection; if the recordset was subsequently changed, closed, or deleted, then the elements of the collection, although countable, were inaccessible. The solution was to put the referenced item into a local variable before adding it to the collection.
Eg:

'use a local variable here ...
strDosage = grsMedList.Fields(intField)
gcollAvailDosages.Add strDosage

[later]

'..otherwise collection contents may be meaningless here:
For intCount = 1 To gcollAvailDosages.Count
lstDosages.AddItem gcollAvailDosages.Item(intCount)
Next intCount

\Frank

ps What is a dictionary????

 

[mrblurgle]

Whoops, Sorry I didn't notice the year, and thought it was only a week old

Thanks, it could be a related issue for me - although I (think I) am only storing a long in the collection, I am pulling it from a recordset so I may be storing a reference to the recordset, but I don't think so - I'll look into it.

The bizarre thing was that when I stepped through the code, I could check the value using a watch, but got a trappable error if I tried to print the item from the collection in the Immediate window and the fatal error if I stepped through the line of code.

The Dictionary object is a new-ish object available from the VBScript DLLs. It implements a bit more functionality than the Collection object and is similar to some Java/javascript objects. You can create one using ...CreateObject(Scripting.Dictionary) - look in the doco. for more details.

Thanks,
Keith

 

[mrblurgle]

Yep. The problem was that I thought I was storing a long but was actually storing the recordset field object in the collection. I think the XP environment is a little less forgiving about default properties vs. object references.
I do think that VB's error trapping could be a shade more robust about it, though!

thanks very much Frank!

 

[JohnYingling]

This is a problem in any object including the dictionary object that accept Variants. If you attempt to store teh default property of an object e.g. Text of a texbox but do not specify the property then a reference to the object is stored.

dctD(&quot;Name&quot = txtName ' stores reference to txtname object
dctD(&quot;Name&quot = txtName.Text ' stores actual string
dctD(&quot;Name&quot = (txtName) ' stores actual string because
' parens force evaluation of txtName as an expression
' thus forcing the default property to be called.

http://www.VBResizer.com

Generate Forms/Controls Resizing/Tabbing Class

http://www.VBCompare.com

Compare Code (Text)

http://www.VBSortGen.com

Generate Sort Class in VB or VBScript