Давайте все таки выражаться корректно. whenChanged ведет себя так, как описано в документации. Но не так, как вы этого ожидали. И да, вам придется написать несколько дополнительных строк кода. Но говорить про “костыли” и “ложные вызовы”, я считаю, некорректно.
1 лайк
Вопрос ни сколько в его поведении, сколько в том, что для распределенного управления он не очень подходит, нужны другие механизмы для большей гибкости и более сложных алгоритмов.
Итак, ребята, это случилось. Правила начали “циклить” на объекте. Буду разбираться, в чём причина, но эффект уже произведён. Наверняка последуют выводы.
Добрый день.
В таком случае если если поведение не соответствует ожидаемому и описанному в документации — создайте, пожалуйста, новую тему согласно правилам, в которой укажите:
- Какое оборудование и как подключено
- Какие версии прошивки и аппаратной ревизии у устройств
- Что вы делаете, какой результат ожидаете, что происходит в действительности
- Приложите ваши правила, а так же диагностический архив
Мы в свою очередь, попытаемся воспроизвести проблему. Если проблема действительно есть — передадим задачу по решению проблемы разработчикам и по результатам вас обязательно уведомим.
1 лайк
Я столкнулся с такой же проблемой, когда нужно было синхронизировать между собой два range значения: две шкалы, одну в процентах, другую в абсолютных величинах. Сначала тоже думал, что взаимозацикленность - это неправильно. Но потом сел, обдумал, и решил, что лучше именно так, как реализовано. Лучше однозначное соответствие логики поведения ожиданиям, чем разная логика, в по сути, нативной функции.
В итоге, я решил похожую задачу таймером. Запрещал взаимное влияние значений в течение 300 мс через флаг, который ставил в одном whenChanged, и по нему игнорировал исполнение кода в другом whenChanged.
1 лайк