WPF / Silverlight: VisualStateManager против триггеров?

Question

Я вижу, что некоторые функциональные возможности между диспетчером визуального состояния и триггерами перекрываются.

<VisualStateManager.VisualStateGroups>
   <VisualStateGroup x:Name="CommonStates">
      <VisualState x:Name="Pressed">
             ... bla bla ...
      </VisualState>
  </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

Или я мог бы пойти

<Trigger Property="IsPressed" Value="true">
          ... bla bla ...
</Trigger>

Когда мне следует использовать одно против другого?

Answer 1

Существует огромное количество совпадений между ними. VisualStateManager был добавлен позже после устранения "боли", которая может возникнуть при использовании триггеров для сложных сценариев. В целом, он гораздо более гибкий и простой в использовании.

Answer 2

Некоторые вещи проще сделать с помощью триггеров, другие легче с VSM.

Основная причина использования VSM заключается в том, что триггеры не поддерживаются в Silverlight. Если вы когда-нибудь рассчитываете перейти на Silverlight, держитесь подальше от Triggers.

Два недостатка VSM:

• Вы не можете легко установить начальное состояние. Лучший способ - установить его где-нибудь в коде, но это больно.
• Не рекомендуется анимировать одно и то же свойство в двух разных группах состояний, но часто желательно при реализации шаблонов элементов управления. Вы можете получить больше детализации в перекрытиях состояний с помощью триггеров, потому что вы можете использовать несколько условий.

VSM, похоже, будущее. Если вы используете Blend, VSM очень прост в настройке.

Answer 3

Зачем использовать VisualStateManager и (не в конечном итоге) использовать триггеры?

Давайте начнем с общих различий между ними.

• Как они стреляют:
  • Триггеры срабатывают, когда свойство меняет свое значение .
  • VisualStates запускаются, когда элемент управления запрашивает состояние из группы состояний .
• Действие, которое они выполняют при увольнении:
  • Триггеры:
    1. Создание через Setter какого-либо другого имущества.
  • VisualState :
    1. Инициирует запрос на изменение статуса на VisualStateManager.
    2. VisualStateManager выполняет VisualTransition перед установкой состояния.
    3. VisualTransition выполняет Storyboard.
    4. По истечении времени, указанного в GeneratedDuration (из VisualTransition), VisualStateManager обновляет свойство CurrentState соответствующего VisualStateGroup элемента управления.
    5. Далее VisualStateManager выполняет начальный VisualState, запрошенный в (1).
    6. И, наконец, VisualState выполняет еще один Storyboard.

И да, вы правы, полагая, что VisualStateManager делает сценарий более сложным, чем триггеры. Однако сложность VisualStateManager позволяет программисту делать вещи, которые триггеры не могут делать (не простым способом):

• Различие между состоянием и переходом между состояниями:
  • Создание анимации во время изменения состояния независимо от самого состояния без создания другого дополнительного свойства.
  • Разрешить повторное использование одного и того же перехода путем правильной установки команд From и To для VisualTransition.
  • Автоматическое управление визуальными проблемами и анимацией (например, остановка анимации перехода и активация другой в середине перехода).
  • Легко добавлять / редактировать / поддерживать / удалять сложные анимации, что облегчает программирование в сложных сценариях.

• Дает большую свободу в способе запуска VisualState: , поскольку его можно сделать с измененным свойством, событиями, методами и т. Д. Даже (это самая волшебная вещь) без выхода из xaml , используя Behavior правильно.

• Реализация нескольких состояний и переходов состояний одновременно: , поскольку вы можете назначить набор групп состояний для элемента управления (a VisualStateGroup), и каждая группа состояний имеет уникальный CurrentState в данное время. Возможно изображение говорит это лучше всего:

• Естественная интеграция с WPF: , поскольку неявно, контроль - это тот, который обрабатывает состояния и позволяет управлять состояниями в виде своего рода дерева элементов управления (parent-control) ), то, что естественно происходит в WPF. Это позволяет вам генерировать очень сложные сценарии всего за пару строк; и, конечно же, не касаясь кода позади элемента управления.

И я уверен, что есть и другие преимущества. Самое интересное, что если вы хотите использовать некоторые из этих преимуществ самостоятельно, используя триггеры, вы в конечном итоге попадете в систему, очень похожую на VisualStateManager ... попробуйте!

Однако ... не всегда хорошо использовать VisualStateManager

Даже при всех этих преимуществах система Trigger не должна сбрасываться системой VisualStateManager. Триггеры - более простая система, но она также имеет свой потенциал.

Лично я бы использовал триггеры для очень простых «примитивных» элементов управления, которые не требуют странного поведения или странной анимации. В этом типе элементов управления сложность реализации VisualStateManager не оправдывает его использование.

Для более сложных элементов управления я бы использовал VisualStateManager, особенно для тех «сложных» элементов управления, которые используют другие «примитивные» элементы управления ( обратите внимание на значение понятий «примитивный» и «сложный» ),Естественно, эти элементы управления имеют сложное поведение в зависимости от взаимодействия с пользователем.

Answer 4

Я думаю, вы можете использовать VisualStateManager (VSM), чтобы создать контракт управления для деталей как глобальное проектное решение и инициировать как реакцию элемента представления в конкретном случае, когда он используется.

Это хорошая практика для реализациипользовательский элемент управления, описывающий его представление как «конечный автомат» и внутреннюю логику перехода.Но триггеры могут реагировать на изменения окружающих элементов управления или данных приложения.

Я думаю, вы можете использовать VisualStateManager при разработке пользовательского элемента управления и триггеры при разработке сложного представления с несколькими элементами управления.

IНе согласен с тем, что главная причина использования VSM - неподдерживаемые триггеры в Silverlight.Вы можете использовать триггеры из Microsoft.Expression.Interaction + System.Windows.Interactivity из Blend SDK.В Silverlight 5 эта функциональность будет доступна в ядре Silverlight.

Answer 5

В дополнение к другим ответам, легче построить "дизайн" опыт вокруг визуальных состояний, чем с триггерами.Например, Expression Blend позволяет вам интерактивно создавать раскадровку, которая будет запускаться для различных визуальных состояний ( video для Blend 3).Это не может быть легко сделано с помощью триггеров.