Re: TCP Newbie Question

Tech-Archive recommends: Speed Up your PC by fixing your registry



On Mon, 20 Oct 2008 03:05:05 -0700, Tym <spamtrap@xxxxxxxxx> wrote:

[...]
I tried comverting it to VB with an online converter, but it throws up an error in the
server.BeginAcceptTcpClient(AcceptCallback, server)

lines as the AcceptCallback is expecting a parameter. Ditto with
ReadCallback.

[...]
I tried pasting it into a new VC# project and it threw even more problems at
me!

I don't know why the C# project would generate _more_ errors. But, there are three basic issues with the code you posted:

-- in VB, you have to explicitly use "AddressOf" with method (Sub/Function) names for delegate types
-- the code you posted is for use in context of a Forms application (thus the Form1_Load() method)
-- the code you posted doesn't include the ClientState class that the example I posted in that thread had

The latter two problems would exist in either the VB.NET or C# version. They can be resolved easily though. For example, you could put the initialization code in the Main() method of a VB.NET console application (though, the main reason the Form1_Load() method is likely to be a problem is that it uses the EventArgs type, which is not likely to be valid if you don't have a reference to System.Windows.Forms). And you can go ahead and add the ClientState class as required by the sample code.

The first issue is easily fixed by putting "AddressOf " in front of each method name for the Begin...() method calls that are causing problems.

Now, that said: all of these errors are things that I would expect an experienced programmer to be able to resolve on their own. If you are using VB.NET and aren't familiar with the syntax for creating delegate instances, then that doesn't bode well for any use of code involving delegates, and especially not code involving multiple threads. The error for the missing ClientState type should be obvious enough as far as fixing. And you should be able to recognize a valid VB.NET console app versus code that's intended for a Forms application, and reconcile the two.

At the very least, you should commit to not just expecting for basic compilation and implementation errors to be solved by someone else, but rather to really _learning_ these things and using errors and mistakes as an opportunity to learn something new.

It will certainly be harder and take longer in the short run for you to try to solve those problems on your own, and you definitely should still ask questions if you have spent some significant time trying to figure things out and still can't. But you'll wind up having a much better understanding of how these things work if you can figure the basic compiler errors out yourself; they are a classic "learning more from mistakes than from successes" situation, and you should take advantage of that. And in the long run, that will make things go much more smoothly.

Pete
.