More a small development note for myself since I generally end up using all the columns in a list when developing with SPGridView’s.
private static void GenerateColumns(this SPGridView gridView, SPList list )
gridView.AutoGenerateColumns = false;
foreach( var column in from string fieldname in list.DefaultView.ViewFields
select list.Fields.GetFieldByInternalName( fieldname )
select new BoundField
DataField = field.StaticName,
HeaderText = field.Title
gridView.Columns.Add( column );
EDIT: This also occurs in Resharper 5.0
Resharper 4.5 breaks the type references when using Linq-To-XSD, which is really lame. Really, really lame since I use it all the time. So, this is what it looks like when you first set your .XSD to a LinqToXsdSchema build action and reference the project (note: I am not talking about using the command line switches to externally generate the strongly typed DAO files but rather using the inherent VS.NET hooks).
This sucks obviously since you lose intellisense, however the freaking project will build correctly! The only way I have found around it is to disable Resharper when accessing your generated classes.
Then it automagically goes back to being able to reference the right types again…
This is more of a quick tip than anything in regards to moles. When using moles, sometimes you might be find yourself executing a safe cast, or trying to, between your Mole and runtime instance type. Why would this happen? Well consider the following simple code:
TypeX x = ReturnAType() as TypeX;
Now this is a problem with moles, because the typecast will fail resulting in x being null. However, the solution is just to stick with variant types when using Moled types, each moled type will have a property representing the Instance (the property is actually the MoledType.Instance property) which will expose the runtime instance. The cool part is the case is built automagically by the compiler :-)