Nothing actually... It just scares the *** out of me that some people here - most likely intelligent people - seriously consider it as an alternative. At least that's the feeling I get after reading the posts above.

Wow... I'm still looking for the joke icons, but it seems that most of you guys here are actually seriously discussing the pros and cons of communism. SERIOUSLY? Come on, are you 5 years old or what?

VE2 wrote:

the rain in spain falls mainly on the plain

the rain in spain stays mainly on the plain FTFY :)

RobCroll wrote:

I like the way they explicitly declare methods as public when the class is implicitly internal.

I can't really see anything wrong with that :confused:

RobCroll wrote:

if you want to pass, hand in your assignments :)

I have already got an A, but thanks for the offer :D

Sure :) First of all, properties should be used in C# instead of get() and set() methods wherever appropriate. Public member names should start with a capital letter. Prefixes such as "arg..." are evil. The constructor parameters should be simply "name" and "sname". The name "SName" is a great example of an unclear and unneccessary abbreviation that should be avoided. I was too lazy to search for reference links, this is what I remember from the guidelines. Somebody correct me if I'm wrong...

See this piece of code:

class Person
{
private string name;
private string sname;

public Person(string argName, string argSName)
{
    name = argName;
    sname = argSName;
}

public string getName()
{
    return name;
}

public string getSName()
{
    return sname;
}

public override string ToString()
{
    return name + " " + sname;
}

}

Now consider these few facts: - the code is in C#, not Java - in case you haven't noticed, this code violates some basic good-style C# coding guidelines - the person who wrote this code teaches C# programming at university - this piece of code was given to his students as a do-it-like-this example - he never, ever uses properties (Java-style getXXX() and setXXX() methods seem to be good enough for him...) - he sometimes names his classes and methods in Czech using diactitics (yes, it compiles fine since VS is Unicode-based, but... WTF?) - And more!

Yes, it's just you... ;P No, seriously, I have exactly the opposite problem - working with winforms is a torture for me, while SL and WPF seems to go smoothly. I guess it's just the matter of personal preference - everybody has to find at least 1 technology to hate.

What you want is near to impossible, or at least very difficult. I believe professional obfuscation tools might be able to do what you need, at least partially, but you can't get those for free. Anyway, no obfuscation algorithm can protect your code. If you keep your method names unchanged - probably because you need descriptive names - then your code cannot really be obfuscated. A good descriptive method name pretty much says what the method does (that's its purpose, in the end), which helps a lot to any potential reverse-engineer. As for the method body, automatic obfuscation usually only consists of renaming all identifiers and a few more well-defined steps. The algorithm has no knowledge of your code and it can only do very little because it must not break your code.

It really depends on the kind of application and who it is intended for. If you do not need any features of the latest version and if you do not use any libraries built with the latest version of the framework, then it might be appropriate to build your project for an older version of .NET. For example .NET 3.0 is pre-installed on all Windows Vista computers and .NET 3.5 ships with Windows 7. Therefore if you chose .NET 3.0 as your target framework, there will be more users able to use your application out of the box.

You are welcome

If HELLO_W is a constant, then the result of the comparison is known at compile time and it will always be the same. I believe the compiler is smart enough to remove such unnecessary conditions... You might get different IL code depending on the compiler settings (Release/Debug).

This should do the job:

string str = new string(buffer).TrimEnd('\0');

Or, if you know the desired length of the string, you can try this:

string str = new string(buffer, 0, length);

If the variable is only allowed to hold certain set of values, I wouldn't use string at all... An enum is the way to go. Enums can be converted to string easily and you can also parse a string to get the corresponding enum value. If, for some reason you really need to use a string, there are several ways to validate it. Using a regular expression might be a good way to do it...

You are welcome!

Make sure the AcceptsReturn property of your textbox is set to true.

I went the other way... I used to use Chrome for a long time and switched back to IE8 recently. IE is slower when rendering, scrolling, executing javascript etc... but at least it has an RSS reader and several more basic features Chrome doesn't have. And all sites work fine with IE8 (which, unfortunately, can't be said about Chrome). In the end, whichever browser you choose, you will always have several reasons to hate it...

I have 2 suggestions: 1. Do not use the Thread class unless you have to, because it adds a lot of complexity (could BackgroundWorker do the job?) 2. I would never use Thread.Join() unless I really had to... What if you just set a flag to notify the background thread about the cancellation and wait for the thread to complete without calling Join()?

Ok. I will try to ignore the fact that you provided way too much code that seems very cryptic and unreadable, while only about 10 lines are related to the error... I will ignore the fact that most of the infrotmation you provided with your code is absolutely useless and irrelevant. I will ignore the fact that the title of your first post is the second worst possible title (the first one being "PLZ HELP URGNT"). And I will also try to ignore the fact that your last post didn't contain that mysterious word starting with "tha" and ending with "nks"... If my previous advice didn't help, there is not much more I can do for you. The best help I can give you is: Read the compiler error carefully. Locate the problem in your code. Check everything on that line, see what parameters are required for each method... And then make sure that the parameters you are passing match the required type. With intellisense and all the support provided by Visual Studio (or whatever tool you use) it should not take more than 23.7865039 seconds to locate and fix such a simple error like a type mismatch... even if you are a beginner!

I would personally use the AutoResetEvent class instead of Monitor. I'm not sure if I understand your problem correctly, but the WaitOne() and Set() methods of AutoResetEvent might do exactly what you need.

I'm glad it helped... Here are 2 more notes to make my answer a bit more complete. I assume you aready know all this, but it coud be useful to someone: - The System.Linq namespace is your best friend when working with IEnumerable(T). - The yield return statement is an awesome language feature... http://msdn.microsoft.com/en-us/library/9k7k7cf0.aspx