Winsock Question Re-Stated

[TheTuna]

I red flagged the previous post for this question because I don't think it was clear enough to ever get an answer.

Here's the problem:

If I unload then re-load a form with a winsock control, said winsock control is unable to connect after the re-load.

Has anyone else had this problem or know of a fix / workaround/bugreport/solution/reason not to freak out?

Thanks Tuna - It's fat free until you add the Mayo!

 

[jonybd]

Maybe your winsock.close
was not called when u are unloading your form

 

[TheTuna]

I wish it were that simple. But alas, ye old winsock tis closed prior to the unload...

It's when the form is actually re-loaded that the problem persists.

Tuna - It's fat free until you add the Mayo!

 

[TheTuna]

Once again, this stuff never fails to amaize me...

What I found out by testing is a total and complete SHOCK

Don't close the winsock, if you do, it keeps that socket open for who knows how long.

ie. Before unloading the form I did this

sockSendRegistration.Close

If i don't do the .close, everything works fine. Also, if I don't unload the form and do the close, it closes fine and re connects fine too.

If I simply hide the form, and close the connection, again, failure!

if I hide the form and show it again without closing the connection, again it WORKS.


Tuna - It's fat free until you add the Mayo!

 

[ADoozer]

you may have seen this already but ill stick it anyways!!!

http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/Q_10328090.html

 

[TheTuna]

Adoozer, thanks for the link... BUT, this link describes a work around that doesn't work! They say to use a dynamically loaded winsock control, which seems very logical. In fact, that was my first idea when I was looking to solve this problem. It just doesn't work. It is possible to load a new winsock control on an incramentally higher index number, but I don't like the idea of doing it that way.

My final solution was to simply NOT use the close method prior to unloading the form. All is fixed.

Thanks
Tuna - It's fat free until you add the Mayo!

 

[TheTuna]

incrementally... I kan aktually speel, honets. Tuna - It's fat free until you add the Mayo!

 

[JohnStep]

Have you tried not to unload the original form with the winsock control?? Just hide it until further need? This should keep the connection open. This is a bad for memory allocation but it should work. Unless, you may want to create a control arrey and see if it forces it to close upon unloading that way.


J Stephens

 

[TheTuna]

This problem is solved, but just so you know, unloading the form is/was manditory for this application. Thanks for the input though. Tuna - It's fat free until you add the Mayo!

 

[strongm]

How was it solved? By not using the close method? I only ask because closing the Winsock control works fine here...

 

[TheTuna]

Let me see if I can explain this better strongm (because I know it doesnt seem like this is possible, but trust me, it is!

My application sends about 120 bytes of data to the server using TCP via a winsock control. After the data is sent and the send complete event fires, normally, I use the close method, which under normal circumstances works fine.

But with this application, the form is unloaded immediatly following the send complete.

Upon subsequent use, the form is loaded again, and new user data must be sent. Herein lies (lied) the problem... the component failed to connect and send the data, the error produced is trapped within the winsock control and reported in the winsock_error event as Address in use.

Reported work arounds say that loading a new instance of the winsock control will fix this, but it did not, because I am in fact, doing that already.

The only thing that fixed this problem was to NOT call the winsock.close method prior to unloading the form.

Everything works fine, the problem is fixed, since I simply do not call the close method.

Thanks for your interest in this one strongm...

Tuna - It's fat free until you add the Mayo!