Как избежать рекурсивного запуска событий в WPF?

Слегка хакерское решение состоит в том, чтобы установить период отключения, в течение которого вы игнорируете последующие срабатывания обработчика событий. В этом случае обязательно используйте DateTime.UtcNow, а не DateTime.Now, чтобы избежать граничного условия перехода на летнее время.

Если вы не хотите зависимости от времени (события могут законно быстро обновляться), вы можете использовать аналогичный тип блокировки, хотя это еще более хакерский:

        private int _handlerCounter;
        private void Handler()
        {
            //The logic of this handler will trigger an 'asynchronously reentrant' callback, so we ignore the next (and only the next) callback
            //Note that this breaks down if the callback is not triggered, so we need to make certain the reentrancy will occur
            //If we can't ensure that, we need to at least detect that it won't occur and manually decrement the counter
            if (Interlocked.CompareExchange(ref _handlerCounter, 0, 1) == 0)
            {
                //Call set on A/B, which triggers callback of this same handler for B/A
            }
            else
            {
                Interlocked.Decrement(ref _handlerCounter);
            }
        }

Вместо того, чтобы вызывать события, реорганизуйте свой код, чтобы обработчики событий для A и B вызывали другой метод для выполнения фактической работы.

private void EventHandlerA(object sender, EventArgs e)
{
    ChangeA();
    ChangeB();
}

private void EventHandlerB(object sender, EventArgs e)
{
    ChangeB();
    ChangeA();
}

Затем вы можете расширить/изменить эти методы, если вам нужно делать немного разные вещи при изменении A напрямую или через B.

UPDATE

Учитывая, что вы не можете изменить/у вас нет доступа к коду это не решение.

Прежде всего, я бы подумал о дизайне, потому что циклические зависимости часто являются признаком плохого дизайна. .

Однако могут быть ситуации, когда такие зависимости — единственный выход. В этом случае я бы предложил использовать частные флаги, указывающие, было ли изменение в B вызвано изменением в A. Что-то вроде этого (обновлено):

public class A
{
    private bool m_ignoreChangesInB = false;

    private void B_ChangeOccurred(object sender, EventArgs e)
    {
        if (!m_ignoreChangesInB)
        {
            // handle the changes...
        }
    }

    private void SomeMethodThatChangesB()
    {
        m_ignoreChangesInB = true;
        // perform changes in B...
        m_ignoreChangesInB = false;
    }
}

Тот же подход следует использовать в классе B. Однако этот подход не обрабатывает изменения из нескольких потоков. Если A или B могут быть изменены из нескольких потоков одновременно, вам придется использовать соответствующие методы, чтобы избежать потери изменений свойств.

Решение Криса, вероятно, является правильным, но иногда мы удаляем событие, вносим изменения и повторно добавляем обработчик событий:

Представьте себе DataContext с событием DataContextChanged:

DataContextChanged -= OnDataContextChanged;
DataContext = new object();
DataContextChanged += OnDataContextChanged;

Таким образом, вы будете точно знать, что ваш обработчик событий, так сказать, не сработает. Однако событие все еще срабатывает;).