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

Ответ 1

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 5

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