Comments by John Brett (Top 19 by date)

Reason for my vote of 3
Your extension method requests all of the custom attributes from the field, then makes the assumption that the first one it finds will be of type DescriptionAttribute. Needless to say, this will fail if your enum uses any other attributes.

It also doesn't address the question of internationalization. A common origin of this requirement is to be able to display a human-readable form of the enum - and that ought to be in the reader's own language.

So not the best implementation of this on CodeProject.

Reason for my vote of 4
A useful approximation of the in-memory costs of an object.

Reason for my vote of 4
The information in the tip is useful and well presented.
Supplying the source as a .zipped .rar file is odd and unhelpful - it means we can't browse the source from within codeproject.
As the sample in the tip shows, the code really does have a massive switch statement on the drive letters - surely even for a tip this should have been refactored into a single function?
I'm also not comfortable with the code actively killing explorer's process - that feels wrong and may have unintended consequences.
Anyway, useful content (even if I do have reservations about the delivery).

John

Reason for my vote of 3
The aspect of this implementation that I don't like is the confusion between being a state-changing method of a class and being a function operating on passed-in parameters.
It both uses the parameter ref node and this.header (which happen to be the same variable), which makes it unclear what this method is supposed to be.

I agree with FatCatProgrammer that the logic should be extracted and shown in isolation.

Reason for my vote of 3
This looks more like an article than a tip to me (it's a complete application, rather than just 'how to do').
The issue I have with the coding is the use of
Application.DoEvents
This is widely deprecated, mainly on account of the opportunity for the code to go re-entrant and can lead to a stack overflow.
It looks like you're facing the issue most programmers faced when Windows (et al) first came out - the logical leap from linear coding to event-driven coding.
I'd be much happier with a solution that used events (e.g. a Timer) to iterate through the animations, and lose the DoEvents and Sleep calls.

Reason for my vote of 5
Nice, although if you're going to all of this trouble you ought to include a try/finally or using(){} pattern to ensure that you're exception-safe

Reason for my vote of 2
First, congratulations on making a working chat program.

However, the code is generally pretty poor, and not something I'd want other people to use as a basis for coding.

Gotos. Seriously? Nowadays, in an OO language? :-(
Global state. Lots of weakly-named variables with global scope in the poorly named Module1.
Using integers for state. We have enums, now.
Using Thread.Abort (and acknowledging that it's poor practice).
Monolithic code. There's very little attempt to break out the various functions of the code, instead building up a few very large functions.

John

Why?
What is the purpose of placing the restriction upon the implementation?