Coding Box

I have just spent the better part of two days fighting a socket bug that turned out to be a simple fix. Isn't it funny how the time consuming ones always turn out to be something simple? I have been using .Net's TcpListener to create a server/client applications. The advantage of using the TcpListener is that it does all of the standard socket setup for you. You also still have access to the socket and the network stream that is used in case you still need the extra power that comes with manipulating them yourself. The way I set this thing up is by having both the client and server loop forever to listen for incoming data. This is done using BeginRead(...) on the network stream. myTcpClient.GetStream().BeginRead(data, 0, size, new AsyncCallback(dataReceived), state); This will have the app listen on another thread so that I can do my other business. When data is received, the callback method that was passed in will be called. What is cool about this is that you can still send o...

I finally had the excuse recently to look into creating my very own plug-in interface. A plug-in essentially allows a piece of software to load dll files (more pieces of code) that it knows virtually nothing about before runtime. I was very impressed at how simple this is using .Net and its reflection implementation. When I began to research this topic, I found all kinds of articles that show you how to achieve this in a particular way. I would later find out that the common way to go about it is very inefficient. The reason for this is that .Net's reflection implementation has some very inefficient routines. Reflection is sluggish by nature; the parts of reflection that are not so sluggish were given special optimization attention because they are commonly used by .Net. I won't go into much more detail on this because I am by no means an expert on the matter, but I will point you to some very good literature. This article will explain some of the insides of reflection a...

Today I ran into a mojor headache. I have a main form that instantiates a secondary form from its constructor. I also register to a receive data event that I have based on a socket. Because the socket uses threading, when my event delegate is called, it is being called from the context of another thread. It is inside the execution of the delegate that I ran into trouble. When I receive data from the socket, I want to open the secondary form and do something with it. Immediately I know that I am going to have to use Invoke on the secondary form in order to safely modify it from the other thread. My original attempt looked like this (I will use an inline delegate here to simplify this listing): void dataReceived() { If(secondaryForm.InvokeRequired) { MethodInvoker myDelegate = delegate { secondaryForm.Show(); //do other work on secondaryForm }; secondaryForm.Invoke(myDelegate)...

This blog will be my attempt to keep track of random coding techniques that I run across, or anything else code related that I find useful. If all goes well, I will begin adding posts soon.