Dynamically evaluating a JOIN expression with Linq

For the last little while I've been toying around with System.Linq.Expressions and a mini SQL parser to see how far I can go with evaluating plain text SQL expressions against arbitrary collections of objects. It's mostly a side project for my own enjoyment but eventually I am hoping it actually turns into something broadly useful.

Results so far I've put on CodeProject:

• http://www.codeproject.com/KB/linq/SqlLinq.aspx
• http://www.codeproject.com/KB/linq/QueryAnything.aspx

It's been awhile but today I opened up that code again and got a basic JOIN operator working. This is cool because ultimately I'd like to be able to join loosely related datasources; say across the mp3 tags in my music collection and the data on my last.fm account.

So just now I've been able to get this unit test to pass:

[TestMethod]
public void SimpleJoin()
{
    IEnumerable source<Person> = TestData.GetPeople();
    IEnumerable families<Family> = TestData.GetFamilies();

    var answer = source.Join(families, p => p.Address, f => f.Address,
        (p, f) => new FamilyMember { Name = p.Name, LastName = f.Name, Location = f.Address });

    var result = source.Query<Person, Family, FamilyMember>
              ("SELECT Name, that.Name AS LastName, Address AS Location 
              FROM this INNER JOIN that ON this.Address = that.Address", families);

    Assert.IsTrue(result.SequenceEqual(answer));
}

This is cool because now I can start generating complex queries without having compile time knowledge of the underlying data structures. Once I get things fleshed out further I'll update things on CodeProject.
CodeProject

A new CodeProject article

I always like  to use System.Diagnostics.Trace to report detailed status to the user. For the longest time I used a handy little WinForms control that inherited from TextBox to do that. Well now that I am hiking up the WPF learning curve I need a new version.

Said version is posted on Codeproject. Check it out if you need such a thing.

C# Property class Part 2

Commenter tonyt (from CodeProject) rightly points out that there are drawbacks to this approach: A C# Property Class.

Why:

Because there is a mountain of core functionalty in .NET that relies heavily on things like property access via reflection (like data binding) and via System.ComponentModel (e.g., TypeDescriptor), none of which support your take on implementing properties.

You can implement INotifyPropertyChanged on any class that offers a more efficient way to get notified about property changes, as it requires only one delegate for each listener, regardless of how many supported properties you have.

He's right. But I still want to explore this approach. What if we take the Property class and have it implement INotifyPropertyChanged?

public class Property<T> : INotifyPropertyChanged
{
    protected T _value = default(T);

    public Property()
    {
    }

    public Property(T value)
    {
        _value = value;
    }

    public event EventHandler Changed;

    public event PropertyChangedEventHandler PropertyChanged;

    public virtual T Value
    {
        get { return _value; }
        set
        {
            if ((value != null && !value.Equals(_value)) ||
                (_value != null && !_value.Equals(value)))
            {
                _value = value;
                OnChanged();                    
            }
        }
    }

    public override string ToString()
    {
        return object.ReferenceEquals(_value, null) ? string.Empty : _value.ToString();
    }

    protected virtual void OnChanged()
    {
        if (Changed != null)
            Changed(this, EventArgs.Empty);

        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs("Value"));
    }

    public static implicit operator T(Property property)
    {
        if (property == null)
            return default(T);

        return property.Value;
    }
}

Now we can create an class like so:

class ViewModel
{
    public ViewModel()
    {
        Status = new Property<string>("");
    }

    public Property<string> Status { get; private set; }
}

Note the switch from a readonly field to a read-only property. WPF binding requires properties and does not work with fields.

And then we can bind to that in XAML like so:

<TextBox Text="{Binding Path=Status.Value}"/>

(assuming that the DataContext of the TextBox is a ViewModel like the one above.)

That should go a little way to addressing tonyt's point (mostly because WPF data binding is so robust).

CodeProject

Why does Bluetooth insist on sucking so badly?

Every couple of years since I had the grand vision of owning wireless stereo headphones (which I still do not have), I purchase some bluetooth gadget marginally more complicated than a cell phone earbud in order to see if the technology has ceased to suck. So last week I bought a mini Bluetooth wireless mouse to go along with my new Netbook (yum on the netbook BTW: buy one; buy one right now).

So I get it home, unpack it and first thing first download the bluetooth drivers. 77 megs. Yes that's right 77 megabytes of driver. Oi oh well. Push forward.

Awhile and a reboot later up it comes. No findy the bluetooth radio. WTF? Oh wait gotta hotkey that to turn it on. Boink up comes Bluetooth but down goes WIFI. WTF? Hotkey, Hotkey. Bluetooth On; Wifi Off. Bluetooth Off; Wifi Off; Bluetooth off; Wifi On.

See something missing in that sequence? (this we can blame I suppose on the maker of the netbook but I think that the general suckiness of bluetooth forced it upon them)

Oh well I think. I'll come back to that later. Let's see if I can get this thing to recognize the mouse. A few pushes to the sync button on the mouse and "Installing new HID hardware..."

"Yay!" I think "Success!" Until... "Your new hardware installed successfully. Please reboot to complete the installation" Uh-oh. So dutifully I reboot; up comes the bluetooth "Let's find some hardware dialog"; push push push; hotkey hotkey hotkey. Nothing. No mouse. Under no combination of pushing and hotkeying does my netbook believe that there is a wireless mouse a mere centimeter away; crying to be recognized.

So I take the whole thing; dump it back in the bag and return it for one of the 2.4 GHz wireless jobs with the nano transceiver thingy. Pop that puppy in and and up it comes; no software install; recognizes the mouse with no intervention from me. Boop; 30 seconds; mouse.

So bluetooth has been around how long now? And it still sucks this bad? This is what happens when a technology tries to be all things to all people. I'm sure the designers of blueooth saw/see it as the last wireless technology stack ever needed. By anyone. Anywhere.

In truth it's a darn fine wireless earbud solution for your cell phone. That's about it. Perhaps I'll check back in a couple of years. In the meantime, nano-transceiver... yum.