public class BooleanLock
{
    public bool Locked { get; private set; }

    public class BlockLock : IDisposable
    {
        private BooleanLock _parent;

        public BlockLock(BooleanLock parent)
        {
            _parent = parent;
            _parent.Locked = true;
        }

        #region IDisposable Members

        public void Dispose()
        {
            _parent.Locked = false;
        }

        #endregion
    }

    public BlockLock Lock()
    {
        return new BlockLock(this);
    }
}

Now I could use it this way :

// Declare a field as a lock
private BooleanLock _myUpdateLock = new BooleanLock();

// Check for lock
private void UpdateSomeProperty(bool reset)
{
    if (_myUpdateLock.Locked)
        return;

    // . . .

And here’s where the lock is set :

// Part of the function is not re-entrant, so we use a lock there
private void OnSomePropertyChanged()
{
    if (some-condition)
    {
        using (_myUpdateLock.Lock())
        {
            // do non-re-entrant stuff
        } <-- lock is released here automatically

The big advantage here is that the C# compiler’s using-block behavior handles complex try-catch scenarios that I would otherwise have had to implement on my own.

bool isDesignMode = LicenseManager.UsageMode == LicenseUsageMode.Designtime
  || Process.GetCurrentProcess().ProcessName.ToLowerInvariant().Contains("devenv");

Unfortunately, I found that there were several methods in containing classes as well as calling classes that expected List<T> objects (even though the callers only used IList<T> or ICollection<T> members). Eventually I ended up having to change calling code and utility helper methods to use an IList<T> or ICollection<T> as appropriate. (Note that exposing the notification list was out of the question as it was not accessible to some of the callers and it is not good practice anyway).

In some cases the code used List<T> specific methods like Find, but if you have LINQ available then you don’t need to use the List<T> methods since you have alternate and usually more useful extension methods that you can use. I suppose I am over-specializing here by talking about List<T> in particular because it’s probably a good general practice to always expose the least derived class that you really need to.

Note that if you really need to expose a solid class without letting the users change the collection, then using ReadOnlyCollection<T> would be the correct approach compared to directly exposing the List<T> or Collection<T> object or their related interfaces like IList<T>.

Here are three variant generic delegate declarations:

delegate T CovariantDelegate<out T>();
delegate void ContraVariantDelegate<in T>(T t);
delegate T1 ContraAndCovariantDelegate<out T1, in T2>(T2 t2);

The rules are the same as with generic interfaces. The covariant delegate can only use the generic parameter as a return type, while the contravariant delegate can only use it as a delegate argument and not as a return type. The third delegate is both covariant and contravariant but with respect to two separate parameters. And here’s how these delegates can be used:

static Derived SomeFunc()
{
    return new Derived();
}

static void SomeOtherFunc(Base b)
{
}

static Derived AnotherFunc(Base b)
{
    return new Derived();
}

private void DoDelegates()
{
    CovariantDelegate<Base> covariantDeleg = SomeFunc; <--(#1)

    ContraVariantDelegate<Derived> contraDeleg = SomeOtherFunc; <--(#2)

    ContraAndCovariantDelegate<Base, Derived> contraCovarDeleg = AnotherFunc; <--(#3)
}

(#1) : Covariance at play here. Even though SomeFunc returns a Derived type, we use it to instantiate a delegate that expects a Base type.

(#2) : Contravariance here. The delegate expects a Derived argument, but we pass it a method that takes a Base argument.

(#3) : This is essentially a mix of (#1) and (#2).

Here’s a more realistic use of variance in generic delegates:

class Item
{
    . . .

    public int Code { get; set; }
}

class Book : Item
{
    public string Title { get; set; }
}

class DVD : Item
{
    public string Description { get; set; }

    public int Duration { get; set; }
}

Item FindItem(string searchText, Func<string, Item> findFunc)
{
    return findFunc(searchText);
}

Notice how the FindItem method’s second parameter is a Func<> object that itself takes a string and returns an Item. Func’s return type parameter is covariant, and that’s what we can take advantage of. The code below shows two methods, one that searches for a book, and the other that searches for a DVD.

static List<Book> books = < . . . >

static Book FindBook(string searchText)
{
    return books.FirstOrDefault(book => book.Title == searchText);
}

static List<DVD> dvds = < . . . >

static DVD FindDVD(string searchText)
{
    return dvds.FirstOrDefault(dvd =>
        dvd.Description.StartsWith(searchText)
        || searchText.Contains(dvd.Duration.ToString()));
}

The following code shows how to call FindItem using a delegate of our choice.

Item book = FindItem("C++/CLI in Action", FindBook);

Item dvd = FindItem("Batman", FindDVD);

In the first call, we pass a method that returns a Book, whereas the method signature expects a method that returns an Item. But since Func<>’s return parameter is covariant, this works fine. Essentially we are passing a Func<string, Book> as a Func<string, Item> argument. It’s the same for the second call too except that we have a DVD instead of a Book.

Now let’s see a contravariant delegate example. Consider the following method:

void ShowItemCode<T>(T item, Action<T> showFunc)
{
    showFunc(item);
}

It takes an Action<T> as the second argument which is a contravariant generic delegate. Now consider the following code:

static void ShowCode(Item item)
{
    Console.WriteLine(item.Code);
}

. . .

Book book = < initialize here . . .>
ShowItemCode(book, ShowCode);

DVD dvd = < initialize here . . .>
ShowItemCode(dvd, ShowCode);

In the first case we are calling ShowItemCode<Book> which expects Action<Book> as the second argument. But we pass ShowCode(Item) which matches Action<Item> yet it works because Action<> is contravariant.

Remember how in the previous entry I had mentioned a case where a covariant parameter type can be used as the parameter type for a contravariant delegate argument? Well, here’s an example of that:

interface ITestCovariant<out T>
{
    //void Bar(T t); <-- won't compile
    void Foo1(Action<T> func);
    void Foo2(Func<T, bool> func);
}

Even though T is a covariant parameter, we can use it as the parameter type for Action<> since Action is contravariant. I have also used it as the first type argument for the Func<> argument because though Func<> has a covariant return type, it’s input argument generic types are contravariant. Similarly for a contravariant interface:

interface ITestContravariant<in T>
{
    //T Bar(); <-- won't compile
    Func<T, bool> Foo1();
    Action<T> Foo2();
}

Here, we have a contravariant parameter T, but we’ve indirectly used it in the return type by using it to set the contravariant parameters in the Func<> and Action<> delegates.

Covariance allows you to use a more derived type than what’s specified by the generic parameter, whereas contravariance allows you to use a less derived type. Generic interfaces can be covariant, contravariant, or both (though not for the same parameter).

Consider the following code:

class Base
{
}

class Derived : Base
{
}

interface ICovariant<out T> <-- covariant parameter
{
}

class Covariant<T> : ICovariant<T>
{
}

interface IContraVariant<in T> <-- contravariant parameter
{
}

class ContraVariant<T> : IContraVariant<T>
{
}

There’s a base class and a derived class, a covariant interface, an implementation of that interface, a contravariant interface, and its implementation. In C# a covariant parameter is prefixed with out, and a contravariant parameter is prefixed with in. In MSIL the symbols + and - are used for covariance and contravariance. (Note : at the time of writing, Reflector does not recognize or show variant generic parameters, but ildasm does show it correctly).

Here’s some code that shows the variance in action:

ICovariant<Base> baseCov = new Covariant<Base>();
ICovariant<Derived> derivedCov = new Covariant<Derived>();
baseCov = derivedCov; <-- covariance

IContraVariant<Base> baseContra = new ContraVariant<Base>();
IContraVariant<Derived> derivedContra = new ContraVariant<Derived>();
derivedContra = baseContra; <--contravariance

In the first case, we were able to assign a more derived generic instantiation to be assigned to a less derived one. In the second case we did the exact opposite. The Base Class Library has been updated to support covariance and contravariance in various commonly used interfaces. For example, IEnumerable<T> is now a covariant interface - IEnumerable<out T>. This lets us do:

IEnumerable<object> objects = new List<string>();
IEnumerable<Base> baseList = new List<Derived>();

That was something you could not do prior to C# 4.0. Now you won’t have to use LINQ’s Cast<>() as often as you may doing now. There are some rules to follow when using variant generic parameters.

For covariant generic parameters, the generic parameter can only be a return type, it cannot be used as a method argument. It also cannot be used as a generic constraint. (Note : A contravariant delegate can be used as a method parameter that uses the generic parameter as its generic parameter type. I’ll talk about it in my entry on variant delegates)

For contravariant generic parameters, the rules are basically reversed. The parameter type can only be a method argument or a generic type constraint, it cannot be used as a return type. Here’s an interface that has both contravariant and covariant generic parameters.

interface IContraAndCovariant<in T1, out T2>
{
    //T1 Foo(T2 value); <-- won't compile

    T2 Foo(T1 value);
}

Here’s a more realistic example of where covariance comes in very handy:

class Item
{
    public void CheckOut()
    {
        Console.WriteLine("{0} checked out", Code);
    }

    public int Code { get; set; }
}

class Book : Item
{
    public string Title { get; set; }
}

static void CheckOutItem(IEnumerable<Item> source, int code)
{
    try
    {
        source.First(item => item.Code == code).CheckOut();
    }
    catch (InvalidOperationException ex)
    {
        Debug.WriteLine(ex.Message); // invalid code
    }
}

CheckOutItem expects an IEnumerable of Item elements, but because IEnumerable<T> is covariant, I can do this:

List<Book> books = new List<Book>()
{
    new Book(){Code = 99, Title = "C++/CLI in Action"},
    new Book(){Code = 101, Title = "Ajax in Action"},
    new Book(){Code = 105, Title = "ASP.NET Ajax in Action"},
};

CheckOutItem(books, 99);

I have passed an IEnumerable<Book> to a method where an IEnumerable<Item> was expected. And here’s a realistic example of where contravariance can be used:

class ItemComparer : IComparer<Item>
{
    public int Compare(Item x, Item y)
    {
        return x.Code.CompareTo(y.Code);
    }
}

private void ContravarianceTest()
{
    List<Book> books = new List<Book>()
    {
        new Book(){Code = 199, Title = "C++/CLI in Action"},
        new Book(){Code = 501, Title = "Ajax in Action"},
        new Book(){Code = 105, Title = "ASP.NET Ajax in Action"},
    };

    books.Sort(new ItemComparer());
}

I used the List<T>.Sort overload that takes an IComparer<T> argument which in this case would have been an IComparer<Book> but since IComparer<T> is contravariant with regard to T, I could pass my ItemComparer class which is actually an IComparer<Item>.

Funnily, now that it’s available it’s kind of hard to think of how people managed to go without this all these years. It’s more the sort of feature that gets a “woah, we didn’t have this before!” response from people. In a later entry I will discuss variance in delegates.

Consider the following two examples :

public void RepeatText(string text, int count = 3)
{
    while (count-- > 0)
    {
        Console.WriteLine(text);
    }

    Console.WriteLine();
}

public void RepeatDecoratedText(string text, string decoration = "Mr.", int count = 3)
{
    while (count-- > 0)
    {
        Console.WriteLine("{0} {1}", decoration, text);
    }

    Console.WriteLine();
}

RepeatText has an optional parameter count with a default value of 3, while RepeatDecoratedText has two optional parameters. The MSIL generated for these methods are as follows (simplified, and not exact) :

.method public void RepeatText(string text, [opt] int32 count)
{
    .param [2] = int32(3)

.method public void RepeatDecoratedText(string text, [opt] string decoration, [opt] int32 count)
{
    .param [2] = string('Mr.')
    .param [3] = int32(3)

[opt] is a parameter attribute that indicates that this parameter is optional and that the default value will be specified by .param entries. These methods can now be called as follows:

RepeatText("Nish");
RepeatText("Ant", 2); 

The compiler generates code with the optional values filled in as needed:

RepeatText("Nish", 3); <-- 2nd param set via .param value
RepeatText("Ant", 2); <-- No extra work needed

You can also now pass an argument by name. This is particularly useful when you want to skip some optional args, but provide others.

RepeatDecoratedText("Nish", count: 2);
RepeatDecoratedText(count: 2, text: "Ant");
RepeatDecoratedText(decoration: "The super", count: 2, text: "Ant");

That gets compiled as:

RepeatDecoratedText("Nish", "Mr." 2);
RepeatDecoratedText("Ant", "Mr.", 2);
RepeatDecoratedText("Ant", "The Super", 2);

So basically, the parameters are either filled in via the named values provided or via the default optional values. Note that you can write optional value methods using attributes too. Example:

public void RepeatTextDuplicate(string text, [Optional, DefaultParameterValue(3)] int count)
{
    RepeatText(text, count);
}

// . . .

RepeatTextDuplicate("Nish");
RepeatTextDuplicate("Nishant", 5);

The MSIL generated for this method is identical to what you’d have got with the direct C# syntax (used earlier).

As with dynamic types, apparently the biggest beneficiaries of these new named and optional parameter features are developers who interop with Office. Just like in VBScript you can now avoid having to provide optional arguments, and can also provide a named argument directly. For others, optional parameters will definitely help reduce the number of method overloads you need to write, and where there are methods that have more than a few optional parameters, the ability to call them by specifying named parameters will result in cleaner and more legible code.

Here’s a simple class that has a dynamic field, a method that has a dynamic argument, and a dynamic property:

class Dynamic
{
    private dynamic data;

    public void SetData(dynamic data)
    {
        this.data = data;
    }

    public dynamic MetaData { get; set; }

    public void Display()
    {
        Console.WriteLine("{0} {1}, {2} {3}",
            data, data.GetType(), MetaData, MetaData.GetType());
    }
}

Using the class is quite straightforward:

private void Foo()
{
    var d = new Dynamic();
    d.MetaData = 100; <-- Int32
    d.SetData(99); <-- Int32
    d.Display();
    d.MetaData = 100f; <-- Single
    d.SetData("hello"); <-- String
    d.Display();
}

Notice how I keep using different types at runtime for calling the same methods and properties. If you look at the IL via Reflector, you’ll see that dynamic types are internally treated as System.Object. Intellisense within VS 2010 will also give you System.Object members since that’s what they are guaranteed to have.

There are three dynamic calls in the Display method. A nested static class is generated inside the Dynamic class, and it will have one static CallSite<> field per dynamic call. In this case, there are three such fields. Whenever the dynamic calls are made, it’s these DLR call sites that come into play. An extremely simplified explanation of what happens is that the DLR internally uses reflection to figure out what type the dynamic object is at runtime. There is also caching done so that type-matching (or mapping) is not repeated unnecessarily. Of course the implementation is quite complex and you could probably spend weeks going through the code in Reflector. Note that if you make dynamic calls in a different method, there will be another static class generated - so it seems to be one inner class per method.

Consider the following simple method:

public void Test()
{
    var type = data.GetType();
}

A class will be generated similar to the following (I’ve made this easy to read - so this is not an accurate representation of the generated code):

[CompilerGenerated]
private static class SiteContainerForTest
{
    public static CallSiteobject, object>> callSiteGetType;
}

And the method Test gets compiled into:

public void Test()
{
    if (SiteContainerForTest.callSiteGetType == null)
    {
        SiteContainerForTest.callSiteGetType = CallSite<Func<CallSite, object, object>>.Create(
            new CSharpInvokeMemberBinder(
                CSharpCallFlags.None,
                "GetType", <-- the name of the dynamic member
                typeof(Dynamic),
                null,
                new CSharpArgumentInfo[] { new CSharpArgumentInfo(CSharpArgumentInfoFlags.None, null) }
            )
        );
    }

    object type = SiteContainerForTest.callSiteGetType.Target(
      SiteContainerForTest.callSiteGetType,
      this.data <-- the dynamic object
    );
}

The call site’s Target will be of type Func<CallSite, object, object>, and the return type is object (because at compile time that’s what the local variable type was defined as, since we don’t know what type it would be at that time). It’s at this point that dynamic binding is done. Fortunately for us, it’s all done behind the scenes and we are protected from having to write all this code ourselves. Assuming data is an Int32 at this time, Int32’s GetType is called (and since it doesn’t have one, Object’s GetType is invoked).

You can also use dynamic types locally (a site container class is generated for the containing method) :

dynamic d = 1;
string s = d.ToString();
Console.WriteLine(s);

d = "dynamic data";
Console.WriteLine(d.Length);

d = 33;

try
{
    int len = d.Length; <-- Invalid dynamic call on an Int32 object
}
catch (RuntimeBinderException ex)
{
    Console.WriteLine(ex.Message);
}

When I try to use the non-existent Length property on an Int32 value, the runtime will throw a RuntimeBinderException. And it even gives a very useful error message : ‘int’ does not contain a definition for ‘Length’.

Overall, one of the most celebrated uses of dynamic types is supposed to be for Office interop. You no longer have to do endless casts and mid-level variables for debugging. It’s just as easy as using classic VBScript. At this point, unless you want to interop with Word or Excel, I can’t think of too many scenarios where this will come in handy. Maybe someone who’s more functionally oriented than I am can think of some common scenarios.

Here’s a simple hack to do this :

private static void FlushKeyboard()
{
    while (Console.In.Peek() != -1)
        Console.In.Read();
}

Now you can use it as follows :

char x = (char)Console.Read();
FlushKeyboard();
char y = (char)Console.Read();
Console.WriteLine("{0}, {1}", x, y);

Even if you enter more than a single character after the first call to Read(), the second Read() will not be affected.

Here’s a small C# code snippet that shows how to do this :

string command = "mailto:abc@abc.com?subject=The Subject&body=Ln 1%0D%0ALn 2";
Process.Start(command);

• A generic Trictionary class [on VoidNish]
  • The Code Project Mirror

The article describes a Trictionary class that is essentially a dictionary except that for each key there are two values, both of differing types. In many cases instead of doing this, the proper approach would most likely to use a struct that would have those two types as members. But there may also be scenarios where you may want to avoid having to unnecessarily create a struct just for this purpose. You could also use an anonymous type, but that’s really not so different in the sense you still end up having a new type in your assembly. Read the article for more info.

Note that the article was inspired by another Trictionary article on Code Project submitted by Joe Enos.

• Trictionary - Multi-Value Dictionary by Joe Enos

string s = "What's cooking in Alabama?";
char[] vowels = new[] {'a', 'e', 'i', 'o', 'u'};
char[] nonVowels = s.Where(c => !vowels.Contains(
    Char.ToLower(c))).ToArray();
Console.WriteLine(new string(nonVowels));

You just need to manually type in the method name (like Where) and once you do that you’ll then start getting intellisense. You just won’t get it for the starting string object. If you really want it there too, you can use an extra IEnumerable<char> variable and then use that instead of the string. Now you will get full intellisense.

IEnumerable<char> chars = s;

The String class is already equipped with a lot of useful methods, and there’s always the Regex class if you really need some complex string manipulation. So I am not sure there are too many scenarios where you’d actually want to use Linq with a string, but to each his own

The second incident occurred on Tuesday night (or rather Wednesday morning). I was at the Grand Hyatt (17th floor) and had gone to bed close to 1 AM as I had gone for a late dinner/chat with an old friend. Around 4:30 AM or so this really loud siren came on and an even louder announcement was repeated instructing all occupants to move to the nearest staircase and to descend to the first floor immediately. It was also announced that the elevators were shut down. I wasn’t sure if it was a fire-emergency or some temporary air-pollution – in any case, I put on my shoes, picked up my laptop and climbed down the 17 set of stairs (16 maybe if they didn’t have a 13th floor, didn’t feel like counting then). I found a few dozen equally incredulous folks downstairs wondering what the heck had just happened. We watched the fire-trucks come and the firemen go up – and all this time we were all out on the streets. A few minutes later, they said everything was alright and said we could go back up to our rooms. There was a further wait of 20 minutes or so as we waited for an engineer to come down and reset the elevator system – and I didn’t want to climb up the 17 floors, not with my laptop. The worst part of the incident was when we found out that some dim-witted inconsiderate jerk had been smoking in a non-smoking floor which was what set off the fire-alarm. So they had to evacuate that floor as well as the floors directly above and beneath it.

The nice thing about the trip was that the summit was pretty good, we had some interesting technical sessions, the food was great, and it was good to catch up with some fellow MVPs and Microsoft buddies – some of whom I’ve only met at Microsoft summits and never outside Redmond.

• The working set of an application is trimmed when its top-level window is minimized

You can simulate this in your code too (under extreme conditions when you really need the memory). In my case I had to do this in an app that loaded very large PNG files - once in a while we’d get a memory exception and then I’d call this method and retry and it would work. It does sound a bit hack-ish but there was nothing else we could do.

[DllImport("kernel32.dll", EntryPoint = "SetProcessWorkingSetSize",
  ExactSpelling = true, CharSet = CharSet.Ansi, SetLastError = true)]
private static extern int SetProcessWorkingSetSize(
  IntPtr process, int minimumWorkingSetSize, int maximumWorkingSetSize); 

public static void ReleaseUnusedMemory()
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    SetProcessWorkingSetSize(
        System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
}

I thought it’d be nice to post this here in case anyone else ever needs this.

Anyway his main issue was that he did not know how to get the type of a ref string argument. C# will not let you do typeof(string&) which is what he wanted. The solution was to use Type.GetType("System.String&"). In case anyone ever has this bizarre requirement, here’s a small sample that shows how this can be done.

class A
{
    public A(){}

    public A(ref string id)
    {
        id = "AAA";
    }
}

class B
{
    public B(){}

    public B(ref string id)
    {
        id = "BBB";
    }
}

class Program
{
    static void Main()
    {
        new Program().Foo();
    }

    private void Foo()
    {
        string s = "SSS";
        Console.WriteLine(s);
        Bar(typeof(A), ref s);
        Console.WriteLine(s);
        Bar(typeof(B), ref s);
        Console.WriteLine(s);
    }

    private void Bar(Type type, ref string s)
    {
        var ctor = type.GetConstructor(
          new Type[] { Type.GetType("System.String&") });
        var arr = new object[] { s };
        ctor.Invoke(arr);
        s = (string)arr[0];
    }
}

Note how I have to copy back the string from the object array. This is because while the string is passed by ref, it’s the reference in the array that’s passed to the constructor - and not the string that was passed as a parameter to the Bar method. The difference may be subtle unless you think about it.

class Base
{
    private static List list = new List();

    public static List List
    {
        get { return Base.list; }
    }

    private Base()
    {
        Base.list.Add(this);
    }

    public string Name { get; private set; }

    public Base(string name) : this()
    {
        this.Name = name;
    }
}

And here’s what a typical derived class would be like :

class Derived : Base
{
    public static Derived Nish = new Derived("Nish");
    public static Derived Andrew = new Derived("Andrew");
    public static Derived Megan = new Derived("Megan");

    public Derived(string name) : base(name)
    {
    }
}

I thought it was all good, and then ran some code that did an iteration of the list :

foreach (Base item in Derived.List)
{
    Console.WriteLine(item.Name);
}

To my tremendous surprise nothing came up and the list was empty. For a full 10 minutes, the idiot that I am, I kept pondering over this and wondering what the heck was going on. Then it hit me just like that. Even though I was accessing Derived.List, that was just a C# syntactic convenience that allowed me to write it that way because Derived did not have a List member at all (the compiler auto-fixes this to Base.List in the generated MSIL). The property was defined on Base, and thus Derived has not been accessed yet when I iterate Derived.List. So Derived’s static initialization has not even happened yet. Once I realized my folly, fixing it was straight forward, I had to bring down the List property to the Derived class. This meant that every derived class had to do that which was a bit of an annoyance but not so much as to be a show stopper. Here’s the correct code (for my simplified example) :

class Base
{
    protected static List list = new List();

    private Base()
    {
        Base.list.Add(this);
    }

    public string Name { get; private set; }

    public Base(string name) : this()
    {
        this.Name = name;
    }
}

class Derived : Base
{
    public static Derived Nish = new Derived("Nish");
    public static Derived Andrew = new Derived("Andrew");
    public static Derived Megan = new Derived("Megan");

    public Derived(string name) : base(name)
    {
    }

    public static List List
    {
        get { return Base.list; }
    }
}

Next time you are using static properties in your base classes, just be a little careful - I know I’ll be.

There are other approaches to solving this too. Reader Arnaud Weil suggests having a table for each enum and the enum id from this table is used to refer to the enums elsewhere in the database. The guys at my current project have a specialized class that emulates enums and also allows the ability to associate meta-information to each enum value (like an image or a description). A third approach would be to use custom attributes and a type descriptor that’d extract the meta-information from an enum type. The old adage is true - there are many ways to skin a cat.

My recommendation is to store enums as strings in the database. Now you can change the order of the members, add and remove members etc. with absolutely no issues. Converting between an enum value and its string name is rather trivial too.

Some of the rules may seem odd. For example, StyleCop will warn you if you do :

if(someCondition)
    DoSomething();

You need to put braces around it as :

if(someCondition)
{
    DoSomething();
}

Funnily I used to do this till a few years ago, then I started omitting the braces for single-line if-blocks because that’s what my colleagues did too. And now I’ve gone back to using braces. And yes the same rule applies for the else statement too.

I’ll be blogging more stuff on my StyleCop experiences. This post was just a quick something to break the bloggers-block that’s infected me the past few months.

Set the main window’s AllowTransparency to true and set the Background to Transparent.

<Window . . .
    AllowsTransparency="True" Background="Transparent"
    >

Now say you main panel is a grid, put a Border control on it as follows :

<Border Opacity="0.9" . . .>
      <Border.Background>
          . . .
      </Border.Background>
</Border> 

Set the border’s background to what you originally wanted the main window’s background to be. Now you’ll find a transparent window background where your editable controls can still retain 100% opacity.

Warning : Setting AllowTransparency to true on the main window potentially results in some very bad performance issues on both XP and Vista since WPF switches to software rendering (in my experience, even with good video cards). Once that happens, animations and video can get pretty unusably slow.

• C++/CLI HowTo : Deriving from a C# disposable class
• Article mirror on The Code Project