Good you solved it! :thumbsup:

You are right. If for some reason you can't prevent duplicate entries, then you can use the following query:

SELECT ArtworkID
FROM (SELECT DISTINCT ArtworkID, DescriptionText FROM Artwork) as t1
WHERE DescriptionText In ("Start Switch","Stop Switch")
GROUP BY ArtworkID
HAVING COUNT(*)=2;

It uses a sub-query to get the distinct values first. The rest functions just the same.

I think the follow query would do what you want:

SELECT ArtworkID
FROM Artwork
WHERE DescriptionText In ("Start Switch","Stop Switch")
GROUP BY ArtworkID
HAVING COUNT(*)=2;

In XAML you could do this by binding the tabItems IsSelected to the IsChecked from the radiobutton. See the example below (for the sake of this example I removed some attributes like Height and Margin)

<Grid>
    <TabControl Name="tabControl1" >
        <TabItem Header="tabItem1" Name="tabItem1" IsSelected="{Binding ElementName=radioButton1, Path=IsChecked, Mode=TwoWay}">
            <Grid />
        </TabItem>
        <TabItem Header="tabItem2" Name="tabItem2" IsSelected="{Binding ElementName=radioButton2, Path=IsChecked, Mode=TwoWay}">
            <Grid />
        </TabItem>
    </TabControl>
    <RadioButton Content="1" Name="radioButton1" IsChecked="True"/>
    <RadioButton Content="2"  Name="radioButton2" />
</Grid>

It can be done with a

List<KeyValuePair<Type, object>>

The example doesn't use the advantages of a dynamic (dynamic binding) over an object (static binding). At this article http://msdn.microsoft.com/en-us/magazine/gg598922.aspx[^] the advantages are explained. Objects and dynamics are for a large part the same with one exception that the bindings aren't resolved until runtime. It is as if you tell the compiler "trust me, I know what I'm doing" :cool: If the dymanic contains a System.Windows.Form.Textbox you could do this

dynamic something = new TextBox();
something.Text = "Hello dynamic world!"; //OK

You wouldn't be able to do this with an object. The programmer has to make sure that the something variable does have a Text property. Otherwise you would get a RuntimeBindingException.

dynamic something = "Change the value to a string";
something.Text = "Hello dynamic world!"; //throws RuntimeBindingException

Another advantage of a dynamic would that you could call a method with a specific signature (because the real type of the dynamic is resolved at runtime).

public void DoSomething(string someValue) { Console.WriteLine("The value is a string: {0}", someValue); }
public void DoSomething(double someValue) {
Console.WriteLine("The value is a double: {0}", somevalue); }

public void CallTheRightDoSomething()
{
dynamic value = 0.5;
DoSomething(value); // The value is a double: 0.5

value = "Now use it as a string";
DoSomehting(value); // The value is a string: Now use it as a string
}

With objects this would give an error. Due to the static binding nature of objects you would get a designtime error. var could solve this, but not as flexible as dynamic. I guess using dynamic would only make sense if you really needs the dynamic binding behaviour. If you have functions that have different signatures to handle the values in your list (string, double, textbox), then it would be necessary to use dynamics. Otherwise you could use object.

:laugh: I guess Silver brought the cavalry. Hopefully not late as usually

The CommandManager does work indeed, as you already knew :) . And would do the trick with probably all viewmodels I have writen. The CommandManager raises the CanExecuteChanged quite often, probably with every user interaction which might change the data of the viewmodel. Although one might not notice a difference in performance. The code I'm using is a little more complicated, but declaring the command is only a little more complicated. Although one might forget to add a listener when the CanExecute conditions change.

        DummySave = new MvvmCommand(p => DoSave(p), p => (!string.IsNullOrEmpty(LastName) && !string.IsNullOrEmpty(FirstName))).
            AddListener(this, vm => vm.LastName).
            AddListener(this, vm => vm.FirstName);

I have found an example of an ICommand implementation using this same standard implementation (CommandManger.RequerySuggested). At this moment I don't know how the CommandManager works. This weekend I'll give it a try. It's allways good to look at alternatives. The custom implementation of the RelayCommand I'm using uses listeners. They listen to the PropertyChanged events of properties of the ViewModel. And when changes are detected the CanExecuteChanged of the Command is triggered.

I'm starting to doubt now. I have read about it in a book about MVVM pattern (Applied WPF 4 in Context, Raffaelle Garofalo, Apress, 2011, ch.8). The ICommand interface is used to build a custom RelayCommand, which should compensate for some lacks in the standard WPF commands. A part of the implementation is the use of the CanExecuteChanged event. It works great. The CanExecute changes exactly when my ViewModel wants it to change it and the View reacts to it. I agree that I cases like mouse events and focus changes you just don't want to interfere with the commands. I'm not sure if it will work or should be avoided to take control of the CanExecuteChanges event in other situations.

The ICommand interface has 3 Members. Beside the Execute and CanExecute methods, there is also a CanExecuteChanged event. You should raise this event when one of the conditions of CanExecute has changed.