A Custom Recursive LINQ Extension

Check out my latest article on Experts Exchange

Using Microsoft Live Writer with Blogger

I was recently pondering my reluctance to post to my blog. I analyzed the problem and came up with the following facts…

• I don’t like the blogger interface for posting to my blog. Especially when I need to post code samples.
• I don’t typically take the time to post something cool I just did with some code I’ve written because I would typically want to upload a new project that people could download and explore should they want to.
• I won’t typically post to my blog after a long day of writing code.

Having made these identifications this is the first step in solving the problems. I’m certainly not a lazy person. I want to post more useful content to my blog so these issues need to be resolved for me personally before blogging on a regular basis will become reality.

Setting up Live Writer with blogger is a snap. I simply went to the Tools menu then Accounts…

… entered in the required URL for my blog, my username and password ( I use my Google credentials ) and viola… Windows Live Writer is up and running. I’m publishing as I go as I write this. A very cool feature.

So far, so good but what about source code? I use the Manoli Formatter which is quite good. I actually downloaded the source code and started to write myself a little blogger application to handle my blog posts or at least allow me to cut/paste the content into the blogger editor. That didn’t pan out due to time constraints and the fact that I wanted something now, now, now.

Anyway, Live Writer seems to bridge that gap for me so far. The previous images (which are totally superfluous) since the setup process is so easy were all handled automagically via Live Writer. That means I don’t have to upload the image to flicker, get the public link to the image, cut/paste and mangle that link into Blogger, etc. OK, I’m making it sound harder than it is but repetitive processes like that drive me insane. That’s why I’m a software developer… I’m too lazy to do anything twice.

So now, lets try some code… If I hop over to Visual Studio and copy some generic Cache code I wrote and paste it into Manoli I get my CSS tagged HTML back and paste it into Live Writer I can preview what my code snippet is going to look like quite easily…

That’s good stuff! I can immediately see that one code line is wrapping due to the format, styling and layout of my blog. Poof! No worries, I can just edit my code in Visual Studio and paste back into Manoli for a quick update…

public class Cache<TKey, TValue>
{
private readonly Dictionary<TKey, TValue> cache = 
    new Dictionary<TKey, TValue>();

public TValue this[TKey key] 
{ 
get 
{ 
return cache.ContainsKey(key) ? cache[key] : default(TValue); 
} 
set 
{ 
cache[key] = value; 
} 
}

public TValue Fetch(TKey key, TValue value)
{
if (!cache.ContainsKey(key))
{
this[key] = value;
}

return value;
}
}

…and there you have it. Easy code that will fit inside my blog nicely without too much hassle. So far, Windows Live Writer just scored mega kudos with me. Look for more blogging soon. Maybe I can keep my New Years Resolution after all. Note: Live Writer is by no means specific to Blogger. It supports many blogging platforms. Let me know what you like and don’t like about it. My 5 minute analysis is “Why wasn’t I using this the minute it was released”? Anyone use any similar applications? Love to hear your stories. My next task: Making the format of my blog more Web 2.0 compliant.

Linq Queries against most collections including ListView, ListViewItemCollection, ControlCollection or anything IEnumerable

The Problem:

You can not run Linq queries against many Framework collections such as ListViewItems and Controls in an immediately obvious manner.

if (list.Items.All(item => item.Checked))
    return true;

The previous code snippet won't compile, won't work and won't shove you in the right direction via IntelliSense, Online Help, or by performing a super-quick Google for the hopelessly attention-deficit disordered such as myself. (more on the Googling later)

The Fix:

Introducing the Enumerable .Cast (TResult) Method

if (list.Items.Cast<ListViewItem>().All(item => item.Checked)
    return true;

Using this method you can rewrite the original code quite easily to this code and Linq query the collection to death with all of your favorite little Linq sledgehammers...

The Why:

Background story for those of you who didn't jump ship to go off using the solution...

I was trying to something I thought would be very straight-forward using Linq. I wanted to sync a tri-state "parent-relationship" CheckBox control with a ListView control that contained "child-relationship" items that had their own respective item specific checkboxes. The parent to child relationship here is conceptual and not baked into the controls, we're talking a simple CheckBox and ListView here.

You've all probably done something similar whether it be with a TreeView using checkboxes containing items with checkboxes. You've certainly seen this behavior if you've ever done a backup and selected what you want backed up on a hard drive. The concept is simple: if all child items are checked or unchecked, the parent CheckBox should be Checked or Unchecked accordingly. If some of the child objects are checked and some aren't, the parent CheckBox should be Indeterminate.

(The backup then flubs your selection, doesn't back up your nicely selected SQL database, and can't seem to adequately backup to your 1TB external HD popping up endless dialogs to let you know how inefficient it truly is but that's a whole different post altogether.)

All fine and dandy, this will be easy, right? Well, the first thing I wanted to do is say something like...

if (listEmployees.Items.All(λ => λ.Checked))
    checkEmployees.CheckState = CheckState.Checked;
else if (listEmployees.Items.All(λ => !λ.Checked))
    checkEmployees.CheckState = CheckState.Unchecked;
else
    checkEmployees.CheckState = CheckState.Indeterminate;

Obviously, my ListView is a list of Employee business objects and my CheckBoxes on my list items are per employee item that I'm displaying. Nothing fancy here.

Note: I use the λ character now for a lot of my Linq statements after reading this question about LINQ to SQL business object creation best practices. I agree that it's technically not the most accurate usage of the Lambda characer however it does clarify the code (to me) and reduces the chance of variable declaration conflicts with Linq queries.

So, I'm ready to compile, skip testing, deem this code ready for production and ship it to my hungry client when this little nastygram pops up during compile...

'System.Windows.Forms.ListView.ListViewItemCollection' does not contain a definition for 'All' and no extension method 'All' accepting a first argument of type 'System.Windows.Forms.ListView.ListViewItemCollection' could be found (are you missing a using directive or an assembly reference?)

Grr. OK, so off to Google I go (oh you do it too!)... I land on
LINQ on ListView.Items (ListViewItemCollection) telling me in no uncertain terms, with an accepted answer, that this just can't be done. Piffle! No way! I'm outraged! Linq can do anything!

So, I typically look at one Google answer like this and go back to the code to see what I, with all my omnipotent developer powers, can figure out. (Usually I'm humbled to admit the same defeat as the previous blog poster but not this time!

So, instinct and too much coffee tells me to look up 2 things...

1.) What are the requirements, more specifically, the "where" clause, if any, of the Linq method "All"
2.) If the ListView.Items property doesn't meet this requirement, then why doesn't it dangit!?!

So, doing a "Go to definition" on the All Linq Extension method I come up with the following in my sweet little meta data viewer.

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate);

The Linq All entension method requires an IEnumerable<TResult> as the source of the extension meaning that only objects that expose IEnumerable<TResult> as part of their class definition will get picked up, and be extensible using the Linq system. There's no where clause, it must be an IEnumerable<TResult> supported object whether by inheritance or interface support.

OK, I was thinking just IEnumerable personally but actually IEnumerable<TResult> makes sense since Linq has to perform anonymous queries using properties of the object that's being extended. Meaning if Linq extended IEnumerable (pure) that's great but when I went to do my neat little .Checked (is true) statement Linq wouldn't know what the heck a .Checked was because IEnumerable would be based on an enumerable object collection.

Fine, makes sense, so what the heck is a ListView.Items collection then? Back over to the "Go to definition" meta lookup for that guy...

[Localizable(true)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
[Editor("System.Windows.Forms.Design.ListViewItemCollectionEditor, System.Design, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", typeof (UITypeEditor))]
[MergableProperty(false)]
public ListViewItemCollection Items { get; }

Uh...OK, so the Items property is this ListViewItemCollection class, but what is that? AGAIN with the lookup I come to...

public class ListViewItemCollection : IList, ICollection, IEnumerable

Aha! It's the problem I just defined in my mind. ListViewItemCollection is just an IEnumerable collection (of objects). The indexer...

public virtual ListViewItem this[int index] { get; set; }

.. is the reason we can easily deal with ListViewItems when we're doing foreach loops on the ListView.Items property. It does the boxing for us. Interesting performance hit, will have to check that out later as Microsoft is probably (hopefully) doing something to defer the boxing cost of each item in the List.

OK, so problem identified but what could I do about it. I'd love to say it was some methodical deduction that brought me to the Cast method but I just did an IntelliSense on the ListView.Items property to see what Linq extensions were available to me.

I started looking into AsQueryable() but I couldn't quite achieve what I wanted. Then, I noticed the little Cast beneath it (in IntelliSense). Poof, that worked.

Voila, now you can run your handy Linq queries against most anything IEnumerable as long as you can, with some accuracy, cast each member to a specific type.

On the Googling: I thought to myself cool! I figured out a problem everyone can use everywhere at all times. Then that creeping feeling overcame me that, "Nah, that was too easy" so I went back to Google. I wasn't a pioneer after all, drat. A Good, practical LINQ example shows you the same technique with a bit more detail and insight (but less comedy) than I came up with. I didn't realize that Linq works on Sequences so you should check this post out as well for a better understanding. Our similarities in deducing the same conclusion was a bit eerie however but I'll let that slide and drink more java (coffee not the language).

I will post my final solution to the checkbox issue itself because it screams reusable code to me. I will refactor my solution into something that isn't bound to specific controls, maybe not even Windows.Forms controls and post it here later.

I made a New Years Resolution to blog at least 4 times a week and mean to keep it up so this is the first installment (late already).

That's all for today and happy Linq'ing...