Advice on Extending Winsock Control

I've decided to try extending the winsock control instead of creating a separate array of infos relevant to each instance of the socket. My option at the moment is:

--- Make a winsock control array
--- Create a collection for extend class
--- Create a new instance of extend class for each loaded instance of winsock then add to collection
--- Set reference to relevant winsock instance for created extend class instance

Is there a better way? Such as declaring a socket object in the extend class? Then making a collection of that class?

Please bear with me since I've just read about classes and collections overnight. Hope you can help.

the best object model will be based on the exact use you plan for it.

a couple of my general guidelines are

dont store object references in collections unless you dotn mind loosing intellisense

I know collections are easy and simple for that kind of coding, but I dunno, I like the array approach just me.

winsock coding is almost always best done with control arrays

what I do is write generic functions that accept individual sockets as arguments, this gives me a safe set of macros to do on a per socket basis..

to handle data processing coming to and from the sockets, i usally use an array of class objects where the class array index = socket index.

there is alot of stuff going on with sockets and it is scattered across multiple events and can be a mess. your style of coding will evolve and new ideas will pop up, this is just where mine has taken me and what has seemed to work best so far

so overall

control arrays of winsock objects

module of functions as macros accepting socket instance for general connection and management stuff

array of classes for socket data handling with methods such as
remoteip,host, state, data, appenddata, clear etc

it also depends alot on what you are using the sockets for, if you were making a http engine, your class data handling would have that http processing built in as well.

I am sure there are alot of approachs to it, and its a complex deal to do right...this is just where mine has gone..

expect it to take some time to get something you are happy with.

Ok, I'll think about it some more. Thanks.

Quote:

---

Originally posted by dzzie
dont store object references in collections unless you dotn mind loosing intellisense

---

I couldn't find an explanation about intellisense in my book and my inet prepaid is about to run out. Can you give me a short explanation, and any pitfalls I might run into if I lose intellisense?

Quote:

---

I know collections are easy and simple for that kind of coding, but I dunno, I like the array approach just me.

---

I was spending to much time (coding and during execution) making the info correlate with the appropriate socket. Since I don't keep unused (closed) sockets, I might as well take advantage of the 1-1 relationship.

Quote:

---

winsock coding is almost always best done with control arrays

---

I decided to keep the control array so I can use the Index parameter in its event procedures. I'll just reference the apt socket as ExSocket after adding the extender.

Quote:

---

what I do is write generic functions that accept individual sockets as arguments, this gives me a safe set of macros to do on a per socket basis..

---

So you pass the socket reference ByRef?

Quote:

---

to handle data processing coming to and from the sockets, i usally use an array of class objects where the class array index = socket index.

---

Maybe I just didn't implement it as well as you did. I was having difficulties dealing with skipped socket indices. I tried inserting a blank array info at the apt index but I thought it was wasting memory. And as I mentioned before I was having difficulties matching the socket with the array member.

I might set the collection member to nothing at the index where a socket is unloaded. I'll think about that suggestion some more.

I'm currently working on the classes and their methods...

intellisense is the pop up window you get when coding that lists all the object members, if you use a collection to store an object reference, unless you first store that reference back into a strongly declared type you will not have the luxary of intellisense when accessing thaty object from the collection. This can lead to hard to find bugs from mistypings

the way I manage loading the sockets is this, I first I put a cap on the total acceptable number say 50, when it comes time for a new connection, I cycle through how ever many there are at present, and I try to reuse any that I can (ie a loaded but closed socket) , if there are none free, then I load a new one.

when I no longer need the socket, I make sure it is closed, but I do not unload it, this way there are no holes and the task is simplified. This also simplifies the data classes, I know that just enough are loaded and there are no holes of forgetting to reload instance X, another benifit is that clsWsData(1) always goes with winsock1(1), no holes...dont worry about the memory or resources...let the preformance of the app be your guide...if you need to ween things out, then do that after you have something working to begin with

for example of generic function

Code:

---

Sub CloseSocket(w as winsock)
  on error resume next
  w.close
end sub

CloseSocket wsData(1)

---

I see where your getting at. Thanks for your help. :)