Printable View
i created a VB.net applicaion
dropped a MSWINSCK control of the form.
set target CPU to x86
dot net 2.0
build project
copy exe and axinterop and interop files for mxwinsock to a client and try and run the applicaiton
the application crashes when opened
i have been using mswinsock for a couple of years with .net so i know it works... why today it started giving me trouble i cannot understand
First off, what error message are you getting?
Second, why are you using mswinsock in the first place? .NET has its own comprehensive set of socket classes.
Why don't you use the inbuilt Socket class in .NET?
It's much better to use with .NET since MSWINSCK was *only* supported on VB6
http://msdn.microsoft.com/en-us/library/sb27wehh.aspx
i honestly have never understood how to create a simple socket server.
with the winsock control i can create a full server application with 20 lines of code
senddata
acceptconnect
data
every example of the socket class contains a hundred lines of code, put the app into a loop, it just seems crazy...
i am really confuesed why someone hasn't written a new control to be as simple as the winsock control but using the new socket class.
the application fails to start, windows has geneated an error. its driving me nutz
it worked yesterday
Yeah, it is more complicated, because the connections are all on different threads. Since VB6 didn't support multithreading, that wasn't even an option. I would guess that is also why there isn't a control quite as simple. If all your connections are on different threads, how does that work in the control, which will be on the UI thread? I suppose that each thread could post messages back to the UI thread so that all incoming messages could be handled there, but that can't be a good idea.
any idea on my issue?
The majority of answers you are going to get are going to be: switch to the dot net socket classes. because a lot of people here don't know winsock.
thanks, but now no one is going to read this and help answer my question
frustrating because i have been doing this for years, and just today i cannot get a project with a winsock control to open on a new machine
Ok, so are you getting an error message? It sounds like it fails right off, and you state that it was working 'yesterday', though I realize you could be speaking metaphorically, there. If you are getting an error message, then where does it take you? Maybe nowhere.
The next step, if you aren't taken to a line of code, would be to put a breakpoint on the first line of the constructor for the startup object, and see whether the breakpoint is hit.
It's really difficult to tell you what the problem is without seeing the error :)
However, if you want to use something which is just as simple as winsck, maybe even easier, I would recommend the jmcilhinney Asynchronous TCP Class which you can find in the CodeBank.
I use it all the time, but it could be good for you to learn how the Socket class works if you develop server applications. It isn't all that difficult if you don't include multithreading capabilities.
application says "... has stopped working"
there is no code in this app... i just created a new app, threw a winsock control on it, set to x86 and clicked build
Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: test.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 4f22c0c2
Problem Signature 04: test
Problem Signature 05: 1.0.0.0
Problem Signature 06: 4f22c0c2
Problem Signature 07: d
Problem Signature 08: c6
Problem Signature 09: System.InvalidOperationException
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Read our privacy statement online:
http://go.microsoft.com/fwlink/?link...8&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
There can't be NO code. If there were truly NO code, then what would be the startup object? As long as there is a startup object, then there is code, so there is a place to put a breakpoint. Though, quite frankly, that does rule out several possibilities.
Seriously, switch to .NET sockets. You won't get anywhere using this legacy ActiveX control and you'll feel much better once you learn how to use the new system.
See: DevServ
of course there is code
for the sake of troubleshooting i ADDED NO CODE
i started a new project and dropped a control on the form.
i am simplifying the issue to get some help resolving... lets pretend this isn't the MSWINSCK but some other ActveX control written in VB6 that i need to port over.
i drop it on a form in VB.net and i cannot install it on a windows machine? there must be a real solution to this issue differnent than finding a different solution.
I don't care. 99% of the time you're using an ActiveX control in a .NET application, you're doing something wrong. This is one of those cases.
The actual source of your issue is probably that the other machine doesn't have the library installed, has a different version installed, or is incompatible with the library. ABANDON IT.
You did try registering the ActiveX control on the target machine, right? You need to do so if you haven't.
As for not wanting to make the move, there are two examples I can think of off hand:
1) JMC has a great Multi-threaded chat application in the CodeBank located right here
2) I have my own library that can be used as well located here.
Either one will suit your needs, and both are written in VB.net. You will probably not get much support here for the old Winsock ActiveX control when there are much better alternatives.
My experience with mswinsock dates back to VB6, as well, so I'm not much help, and I would agree that it isn't something many people deal with, but my point for studying the problem remains, especially if you have some controls on the form. The point behind the breakpoint was finding out definitively whether the problem was arising before or after the start of execution. After all, wouldn't it be kind of a shame to be blaming the ActiveX control when it turns out that you tried to assign something to a control before the control had been created, which would also fail prior to starting the app? You appear not to have an error message that specifically implicates the ActiveX, so I would go about the investigation as if it wasn't the ActiveX control, and only blame it when you have good reason to. Of course, you might very well have good reason to blame the OCX, but that hasn't been made clear, yet.
A quick 5 seconds of google showed a couple of threads with the InvalidOperationException using this control and it was .... register the ocx using Regsvr32. So give that a go first.
shaggy hiker,
i know its the actveX control because if i start a new project and build it the application works. then if i add the activeX control and build it it fails.
i do not add any code on my own
How about what Grimfort suggested?
thanks Grimfort
i just registered the ocx and all is good.
i used to be able to put the ocx in with the applicaition and it found find it automatically, that stopped working... no clue why!
I did not in fact mention this first, so rep formless ;). I just noticed that you did not reply to this comment.Quote:
Originally Posted by formlesstree4
i tried regsvr32.exe and it failed
i had to use
C:\windows\syswow64\regsvr32.exe mswinsck.ocx
on windows7
i still don't understand why the first bunch of CPUs i set up all worked without having to register it
i got lost chasing my tail! thanks
They wouldn't happen to have been all 32-bit systems, would they?
EDIT: Alternatively, could they have already had the OCX registered because of something else that had been installed earlier?
XP, 7-32, and 7-64
very confusing... but atleast im back up and running
thanks
I wouldnt be a very kind person if I didnt advise you to abandon that OCX. I wrote an auto update component from scratch using this control in VB6. I even wrote my own protocol for it. The application consisted of 3 parts. A server that can act as a client as well, a main server to upload to the server/client component and a client component for the application that uses the updates.
Writing these applications was a nightmare because of how terribly limited and stupid that control is. My main issue with it is that you cannot receive data while there are any functions on the call stack which meant DoEvents was an unavoidable necessity which caused endless headaces. If you plan on writing any useful tool to use sockets, I strongly advise you use the .NET alternative.