Vishful thinking…

Using ‘params’ as a part of delegate definition !!!***???

Posted in Uncategorized by viswaug on September 19, 2007

Today I just got curious about how the .NET compiler will handle a delegate definition with a ‘params’ parameter that will let you specify a variable number of parameters on a method. I know it doesn’t make sense but that i was curious as to how the .NET compiler will react to it. After a quick test, the results were somewhat expected. Here are my observations

  • To my dislike, the .NET compiler did not complain about the following definition

delegate void TestDelegate(int value, params object[] others);

  • I was actually able to create an instance of the delegate for the method with the following definition

No Error here

TestDelegate ni = new TestDelegate(IntCompareValidate);

Method definition

        private void IntCompareValidate(int value, object other1)

        {

            //Do something

        }

  •  But the compiler did not let me create an instance of the delegate for the method with the following definition

Error here. ” No overload for ‘IntBetweenValidate’ matches delegate ‘MockProject1.TestDelegate’ “

TestDelegate ni = new TestDelegate(IntBetweenValidate);

Method definition

        private void IntBetweenValidate(int value, object other1, object other2)

        {

            //Do something

        }

Just thinking a little bit more about it, I was thinking maybe the following would have been better. But then again I also do think that the .NET compiler should throw an error on the delegate definition instead of reacting the way it is.

No error here.

TestDelegate n1 = new TestDelegate(IntBetweenValidate);

TestDelegate n2 = new TestDelegate(IntCompareValidate);

 

Error here.

TestDelegate n1 = new TestDelegate(IntBetweenValidate);

n1 += new TestDelegate(IntCompareValidate);

 

What I am trying to say is that there should not be an error as long as all the functions added to the delegate have a consistent signature and there should be an error when they are not. But it is definitely going to be hard for the compiler to implement the above. But then again if you can do the above, the purpose of the delegates are kind of defeated. But it is just a thought…

What do you guys think?

Using custom names for the ConfigurationElementCollection entries

Posted in Uncategorized by viswaug on September 19, 2007

I have been using the .NET configuration library pretty extensively and one thing about using the ConfigurationElementCollection kind of just kept bothering me. All of my custom sections implementing ConfigurationElementCollection always used “add” as the default element name for its entries. I wanted it to be named something more meaningful than “add” which did not make sense all the time. For example, I wanted to be able to use “entry” as the element name instead of “add” like shown below.

ConfigurationElementCollection

Nothing the documentation for the .NET configuration stood out to me that will let me use a more meaningful name. Using a different custom name for the element entries didn’t turn out to be hard to. It was just a matter of looking in the right places to figure how to get it done. This can be accomplished by decorating the property of the custom ConfigurationElementCollection type in the ConfigurationSection with the ConfigurationCollectionAttribute and specifying the “AddItemName” which is an optional parameter like shown below.

    public class TestSection: ConfigurationSection

    {

        public TestSection() { }

 

        [ConfigurationProperty(“NameValues”, IsDefaultCollection = true)]

        [ConfigurationCollection(typeof(NameValueElementCollection), AddItemName=“entry”)]

        public NameValueElementCollection NameValues

        {

            get { return (NameValueElementCollection)base[“NameValues”]; }

        }

    }