How can I keep track of state DRY-ly?

I am trying to keep track of state in a WPF application using MVVM. I just want there to be one state active at a time, but the way I'm currently doing it seems unreliable and not very DRY.

Here's an abstracted version of my code:

public class ApplicationStates
{
    public void SetStateOne()
    {
        IsThisStateOne = true;
        IsThisStateTwo = false;
        IsThisStateThree = false;
    }

    public void SetStateTwo()
    {
        IsThisStateOne = false;
        IsThisStateTwo = true;
        IsThisStateThree = false;
    }

    public void SetStateThree()
    {
        IsThisStateOne = false;
        IsThisStateTwo = false;
        IsThisStateThree = true;
    }

    public bool IsThisStateOne { get; set; }
    public bool IsThisStateTwo { get; set; }
    public bool IsThisStateThree { get; set; }
}

My plan is to bind my view's appropriate XAML objects to the boolean properties to maintain the view's state. I would like to continue having objects that I can bind to where they can do things depending on whether they are set to true or false.

Any ideas on making this more DRY, or is there a completely different, better way to architect this?

EDIT 1

I would like my XAML to look somewhat like this:

<Button Visibility="{Binding IsThisStateOne, Converter={StaticResource boolToVisibilityConverter}}"/>

<Button Visibility="{Binding IsThisStateTwo, Converter={StaticResource boolToVisibilityConverter}"/>

That way I can have what I need visible or not based on the state. And the state would change based on changes in the ViewModel.

Conceptually, since there are more than two states, I could make a converter that checks the name of a string converter parameter ("IsThisStateOne", "IsThisStateTwo") against the string of the enum, but that gets back into magic strings and duplication of non-type-safe code which I would like to avoid.

I understand databinding to the enum directly, I guess I just don't understand how to change the state of that enum (I can have a description string, but I don't think I can change it).

EDIT 2

Removed the enum. I don't really care if there is an enum involved or not, I just thought it would make things a little more strongly typed.

I guess I just want to know if there is a better, established design pattern for this type of requirement.