This is the first installment of what I hope to be many short bits of guidance about correctly resolving some of the more complex warnings coming out of FxCop and Code Analysis.

The CA1300 warning is specifically about the right-to-left or left-to-right reading order of a message box. The documentation for the warning alludes that a message box doesn't automatically inherit the containing form's reading order or the reading order from the user's current culture. Although, I can't find any documentation that confirms either.

In any case, this is a rather complex warning to resolve, you possibly have to traverse the form's lineage (when reading order is inherited) to find the reading order setting. The example fix in the documentation basically puts this logic in the code that calls MessageBox.Show. This is very un-resuable and couples the logic not only to the containing class but to the method it's contained within. My solution attempts to allow resolution of CA1300 with as little coupling as possible and little or no changes to existing code.

My solution is obviously going to implement the extra logic in a new class; but I'll be implementing in a way where you don't have to change your existing calls to MessageBox.Show. My resolution extends the Form class and provides a MessageBox property that is implemented with a protected nested class that provides Show methods with all the same signatures as System.Windows.Forms.MessageBox.Show. The only requirement to using this class is that you haven't explicitly used the full namespace when calling MessageBox.Show, like 'System.Windows.Forms.MessageBox.Show("text", "caption")'.

The following is the class that extends Form using a protected class to implement a MessageBox property to redirect calls to MessageBox.Show–which eventually creates the appopriate MessageBoxOptions value and delegates to System.Windows.Forms.MessageBox.Show.

I've attached a non-web-site friendly version of the class in the attachements, that includes more comments and less line breaks.

Now, the only change to the original code to resolve the warnings is the addition of a using namespace directive and a change to the form's base class (and in this example, a change to the CodeAnalysis suppression):

For those observant readers who noticed the Code Analysis suppression of CA1822. This appears to be no longer needed with Visual Studio 2008 (at least Beta 2, I haven’t tried previous releases of Orcas), it recognises those methods as implementations of an interface that must not be static and therefore no longer complains.