A look at his post history suggests he will never learn

Keep your eyes open, you might spot alternatives.

No, the point I was making was that you are inheriting behaviour. Interfaces have no behviour thus the problem is different. I agree on the what constitutes Good and bad design and perhaps Microsoft could have came up with a MI solution that worked.

Keep your eyes open, you might spot alternatives.

Christian Graus wrote:

That's just plain retarded

Really, I hope you are not refering to my example. I was trying to raise a point about it.

Keep your eyes open, you might spot alternatives.

The fundermental problem is there is a chance that a class can alter the behaviour (override) of a method in a base class. Now if 2 classes do this (override the same base class) and you inherit both these classes then you can have a situation where you dont know which implementation of that method you are calling. There are other issues, but that is the one I can explain in the shortest amount of text. -- oh and as far as interfaces go; as the interface does not define the implementation of the method, it is fine to implement multiple interfaces.

Keep your eyes open, you might spot alternatives.

I don't know there is although once you have installed it the help guide has alot of information to get you started.

Keep your eyes open, you might spot alternatives.

Yeah, I would have thought there was some way of knowing, since Vista makes that judgement on who is privileged enough to use the glass effect. :laugh:

Keep your eyes open, you might spot alternatives.

Not sure if this is exactly what you want but I did find this video interesting on MSDN Nuggets

Keep your eyes open, you might spot alternatives.

There really is no 'Explicit' deletion of managed objects in .net like there are in other languages such as c++. You will have to always wait for th GC to do it stuff. obj.Dispose is just a clean up method really designed for releasing unmanged resources like handles. The Dispose Pattern discusses disposing of objects

Keep your eyes open, you might spot alternatives.

By the very nature of it being a constructor it is supposed to construct the object. Now what ever language you use it should be in a valid state after construction, but there are some things that incure too much of an overhead to be placed inside a constructor. I would avoid starting threads or calling services in there as it makes it very hard to use in the calling code as you may want to pass the reference around. Having said that the behaviour of the class may change if a thread is not started so either well document it, and/or think about more about how the class is going to be used and design it accordingly. ;)