@Wayne Golding Thanks so much for all your help.
@Wayne Golding I’m having a bit of trouble trying to get the number of ActiveSockets. I wrote my client app to connect and stay connected indefinitely so I could test my code and I’m still getting a -1 from activeconnections.ubound.
It’s a console app so no window properties. I have a ServerSocket called SckListen. Here’s the code I am trying to implement. Can you tell me what I am doing wrong? Thanks.
dim ms() as TCPSocket
dim mServerSocket As New SckListen
ms()=mServerSocket.ActiveConnections()
I always get -1 from ms.Ubound
@Wayne Golding Thanks I will.
[quote=256391:@Ryan Haynes]
dim ms() as TCPSocket
dim mServerSocket As New SckListen
ms()=mServerSocket.ActiveConnections()
I always get -1 from ms.Ubound[/quote]
You should always get -1 from that code. mServerSocket isn’t listening yet, so it can’t have any active connections. Perhaps you should use the actual serversocket that you have in use, instead of creating a new object here.
@Wayne Golding Thanks I knew I had to use App.ServerSocket somehow and the way I was using New wasn’t working but I wasn’t sure how to actually call the ServerSocket to use the reference correctly and your example showed me exactly what I was doing wrong. I have it working now so thank you.
@Tim Hare Hi TIm! Long time since I’ve spoke to you on here. Thank you for the reply you are exactly right I wasn’t using the actual ServerSocket I had in use.
I still don’t understand why when you create a property off the App named the same thing as my ServerSocket it just works together? I have it working, but it would be great to understand the reasoning behind this.
It’s all a matter of scope. When you Dim x As New y x is only available in that method, when you x = New y where x is a property of a class or module it’s scope is much wider and can therefore be referenced from elsewhere. Also when you Dim x … that object/item will “go out of scope” when the method completes which will most likely result in the object being destroyed. I say most likely because you can create references to that object that may have other scopes, for example:
Dim mySocket As New Server Socket
App.mySocket = mySocket
@Wayne Golding So it has nothing to do with naming the ServerSocket property of app the same thing as the actual ServerSocket. I could have named them both something unique as long as I create a property and dim the property = new ServerSocket so it has a wider scope. I see now, thanks.
It’s better that they have different names. The compiler chooses the variable with narrower scope, so if you name a local variable the same as a global variable, the local variable “hides” the global one and prevents you from accessing it.