Feeds:
Posts
Comments

Archive for February, 2011

Recently, someone asked this question on the CodeProject forums where the OP wondered if reusing the socket would mean he’d get the same client endpoint. This is the gist of my response to him.

Calling Socket.Disconnect(true) will internally result in Winsock’s DisconnectEx function being called with the TF_REUSE_SOCKET parameter.

From the docs:

Prepares the socket handle to be reused. When the DisconnectEx request completes, the socket handle can be passed to the AcceptEx or ConnectEx function.

So it’s only the socket handle that will be reused. This has nothing to do with your local endpoint.

Socket reuse is meant for fairly advanced use, where you know exactly what you are doing. It’s typically used in high performance heavy traffic TCP servers. The idea being that by reusing a socket, you save some time (the time that would normally have gone into allocating that socket and its resources). So what some server developers do is to have a pre-created socket pool that they pull sockets from as and when required.

So in my opinion, for a client side TCP application there is never a good reason to reuse a socket.

In short, always use Socket.Disconnect(false) unless you really know what you are doing.

For some reason, this is not so well documented and leads to a lot of confusion.

Read Full Post »

Well, that’s not really possible but often people do ask if they can do this. Here’s a solution I recently gave someone which comes quite close which uses a singleton class instead of a static one:

class Test
{
    static Dictionary<int, string> map = new Dictionary<int, string>();

    private Test() { }

    private static Test instance = new Test();

    internal static Test Instance
    {
        get { return Test.instance; }
    }

    public string this[int i]
    {
        get
        {
            return map[i];
        }

        set
        {
            map[i] = value;
        }
    }
}

And here’s how you would use this:

Test.Instance[3] = "hello";
string s = Test.Instance[3];

Read Full Post »

The Winforms DateTimePicker has this odd behavior. If you set focus to either the day or the year, then when you tab out of the control and tab back in, focus is not restored to the month as it is by default (even if you reset or change the DateTime value for the control). There is no elegant way to resolve this as the control does not expose those inner controls in any way. You could send mouse/keyboard clicks to change focus, but it’s way simpler to use this arguably ugly hack. The code below will force the control to recreate itself and thus we reset focus to its default state.

var format = dateTimePicker1.Format;
dateTimePicker1.Format = DateTimePickerFormat.Custom;
dateTimePicker1.Format = format;

The trick is to force the control to internally reset itself by changing the Format and then setting it back to what it was. The code above assumes that it is something other than Custom.

Read Full Post »

This question was recently asked in one of the Code Project forums. Here’s what you need to do:

generic<typename T> ref class GenericList
{
public:
    T GetNext()
    {
        T temp = T();
        return temp;
    }
};

In the above code snippet T() is identical to default(T) in C#, and will generate the exact same msil.

Read Full Post »

Follow

Get every new post delivered to your Inbox.