>>>>>Is there any difference between defining a delegate inside a class as opposed to outside it? If so, what?
>>>>
>>>>When you declare a delegate you're actually creating a class (System.MulticastDelegate) so doing so inside a class is the equivalent of creating a nested class. Couple of considerations (there may be others):
>>>>If the delegate is associated with a particular class then declaring it within the class may provide more intuitive syntax.
>>>>OTOH if you place it inside a large class you have to instantiate the containing class just to use the delegate.......
>>>
>>>Viv,
>>>
>>>>OTOH if you place it inside a large class you have to instantiate the containing class just to use the delegate.......
>>>
>>>Do you mean that, if a delegate is declared inside a class, you have to instantiate that class, just to use the delegate ?
>>>
>>>If yes, I don't think so
>>>
>>>I think a declaration of a delegate is just a declaration
>>>
>>>

>>>	class test2
>>>	{
>>>		
>>>		//______________________________________________________________________
>>>		static void Main()
>>>		{
>>>
>>>			AClass.TheDelegate func = PrintOne;
>>>
>>>			func("hello");
>>>			
>>>			Console.ReadLine();
>>>
>>>
>>>		}
>>>		//______________________________________________________________________
>>>		static void PrintOne( string s )
>>>		{
>>>			Console.WriteLine(s);
>>>		}
>>>		//______________________________________________________________________
>>>	}
>>>
>>>	public class AClass
>>>	{
>>>		public delegate void TheDelegate( string s );
>>>	}
>>>

>>
>>You're right. But it's not a delegate specific thing - *any* nested type is instantiated directly- I didn't think it worked that way!
>>I thought I'd read somewhere that nested classes can access variables in the containing class but I guess that's not right (haven't tried it tho) And I think I'm right about the delegate declaration causing the compiler to create a sealed class derived from Multicast delegate.
>>Best,
>>Viv
>>
>>Ah: http://books.google.co.uk/books?id=Dy-ro5dFp5MC&pg=PA260&lpg=PA260&dq=sealed+class+BinaryOp&source=bl&ots=xJS6LAIq0P&sig=qa4RHaVaeKqE5Ofq9IKjjfE07H0&hl=en&ei=aTPgSs_kNoTKjAeuzJClBg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CA8Q6AEwAQ#v=onepage&q=sealed%20class%20BinaryOp&f=false
>
>
>
>> And I think I'm right about the delegate declaration causing the compiler to create a sealed class derived from Multicast delegate.
>
>You are
>
>>I thought I'd read somewhere that nested classes can access variables in the containing class but I guess that's not right (haven't tried it tho)
>
>That's true. A nested class can access members of the hierarchy above - just tested it. member = static or constant
>For instance members you need an object reference. But static or not, the nested class can access private members of its parent classes
>
>

>	class test2
>	{
>		private static string prop;
>		private string ll;
>
>		//______________________________________________________________________
>	
>		class NestedOne
>		{
>			static string nestedProp;
>			private string nestedProp2;
>
>			class NestedTwo
>			{
>				string a = prop;
>				string b = nestedProp;
>
>				string c = new test2().ll;
>				string d = new NestedOne().nestedProp2;
>			}
>		}
>	}
>

Hi & Thx,
My original impression was that the nested class could access non-static members of the containing class without explicitly instantiating it - thus my supposition that the containing class was automatically instantiating along with its nested class..
Live and learn (although I think I'm on the 'live and forget' side of the curve :-{ )