*some* help please

[ExcalibursZone]

I've posted this before, got an answer in the com/active x forum, but non-helpful as it pertained very little to my problem. Here's the situation:

An object that I've created will not terminate properly. The program does not terminate abnormally (ie end, an error, etc.) and in actuality after I set the object to nothing it continues to use subs and functions that are located within it. When the system timer checks to see if the socket's status is connected, (the system timer is shared by all objects in game) it sends a signal to the object to shut down. The annoying part is: This object is the one that doesn't terminate properly.

Now, I store all active player objects in a dictionary. This is great for the sheer ease of checking if a name is already in use. Anyway, I am using a wrapper class around the dictionary, which is great because I've added quite a bit of extra functionality to it. When I send the player object to be added to the dictionary, should I set it as ByRef or ByVal? I understand the difference between the two methods. (ByRef more or less sends a pointer to the actual object, ByVal sends a copy of the object.) How would I go about the release & destruction sequence? IE: Should I set the object to nothing and then remove it from the dictionary? or visa versa?

I did some testing and found that if I don't set a player object to nothing but just remove it from the dictionary the class_terminate will go off. (IE initial listen object gets set then added then removed in that order and the terminate event will fire.)

If anyone can help me sort this out, please let me know. Thanks.

[robinm]

When you terminate the Object, is the wrapper class for the dictionary still active within the project ?

[Paul Warren]

ExcalibursZone - just seen your rant in Chit Chat so thought I'd give this a go. If it doesn't work there are other things that may be causing your problem -

Tactic Number One :

Make sure you haven't got a public reference in the dll to something that's been passed byRef to it. For example, if you pass the players byRef then store them in a dictionary, which is used throughout the dll, you are effectively creating a link from the dll into the caller. So, when you set the object to Nothing in the caller it can't destory it because there's still a reference in existance coming from the other direction. Before setting the object to nothing in the caller try running a tidy up routine which destorys the items in the dictionary and anything else that is using byRef so there's no links from dll to caller.

Basically this is called a circular reference and it's the biggest reason for objects being left in memory when they should have been destroyed. ( .Net cures this by the way ).

A -> B -> A : Destory the link from B to A before A to B

Hope that isn't as confusing as I think it is but I'm a bit busy at the mo.

[ExcalibursZone]

Thanks for the responses Paul & robinm:

robinm:
When you terminate the Object, is the wrapper class for the dictionary still active within the project ?
What happens is this: On connection request of the socket, the listen socket creates an instance of the player object, which is assigned some preliminary data (request id, remoteip, etc) then it is added (originally ByVal) to the dictionary located in the PlayerCollection class (the wrapper) after which the logon sequence starts and it leaves the sub (I can't figure out how to set the object to nothing in the connection request sub this is where the problem is stemming from). The wrapper class needs to be open throughout the life of the program because it keeps track of which players are currently online.

Paul Warren:
ExcalibursZone - just seen your rant in Chit Chat so thought I'd give this a go. If it doesn't work there are other things that may be causing your problem -

Tactic Number One :

Make sure you haven't got a public reference in the dll to something that's been passed byRef to it. For example, if you pass the players byRef then store them in a dictionary, which is used throughout the dll, you are effectively creating a link from the dll into the caller. So, when you set the object to Nothing in the caller it can't destory it because there's still a reference in existance coming from the other direction. Before setting the object to nothing in the caller try running a tidy up routine which destorys the items in the dictionary and anything else that is using byRef so there's no links from dll to caller.

Basically this is called a circular reference and it's the biggest reason for objects being left in memory when they should have been destroyed. ( .Net cures this by the way ).

A -> B -> A : Destory the link from B to A before A to B

Hope that isn't as confusing as I think it is but I'm a bit busy at the mo.

The player object is global to the entire program. Which is one of the reasons why I believe there is such a stubborn problem ... Do you think making it a local variable only to the functions that use it and killing the global scope of the object would work? when a local object is declared, and you don't set it to nothing at the end of the method will it continue to exist and eat memory or is it destroyed in much the same way as integers and strings? I can't wait for .net so I can program this puppy the right way, but vb6 is working well aside from little quirks like this.

BTW If you happen to be online around 7 PM EST and the page here:
http://lyonesse.dhs.org/mudstatus.html says that the mud is open, you can log on at lyonesse.dhs.org port 7500 via a standard telnet client (or a mud client if you have one). Preferably one with a chatbar at the bottom of the screen. You can see what I'm working on from a players perspective.

Again thanks to both for your responces. any further help would be most appreciated.