Попробую описать всю ситуацию целиком и достаточно подробно.
Это та же проблема что и например с выключателем. Вы можете это наблюдать когда включаете на смартфоне Bluetooth.
Это связано с тем, что само действие происходит спустя какое то время после переключения выключателя. А так же то что это действие может совсем и не произойти, а отмениться. А может и произойти само, например из другой программы. В нашем случае время, это задержка связи которая есть всегда. Плюс логика контроллера, определяющая можно включить или нет в конкретной ситуации. Или контроллер сам решил включить, так тоже бывает.
Это все выше описанное так же легко переносится на числовые данные, которые вы хотите передать в контроллер.
В GUI вы выражаете свое желание что то сделать, например включить выключатель и включаете его на экране. Когда это желание поступит в контроллер, логика контроллера может не дать его включить в зависимости от текущей ситуации. Или же логика контроллера может сама включать или выключать без вашего желания.
У выключателя появляется как бы 4-е состояния: выключен, пользователь хочет включить, включен, пользователь хочет выключить, выключен. Причем два состояния, включен и выключен, могут быть установлены только на стороне контроллера, так как только контроллер знает реальное состояние объекта, включен он или выключен. А состояния, выражающие желание пользователя, устанавливаются в GUI. У числового поля ввода таких состояний будет два, это текущее значение из контроллера и желаемое значение. Так же логика контроллера должна отдельно обрабатывать эти желания пользователя, и после обработки желания этот факт должен передаться обратно в GUI, что бы перерисовать элемент на экране. Элемент управления на экране должен отображаться таким образом, что бы пользователю было понятно в каком состоянии он сейчас находится, в состоянии желания или желание уже совершилось, или не совершилось)). В случае с цифровыми данными он должен отображать как введенное желаемое значение, так и текущее значение из контроллера, то есть две цифры.
Таким образом, для передачи любых данных в контроллер мы имеем достаточно сложный элемент и сложные процессы обмена данными по связи. Как минимум желание пользователя должно передаваться из GUI в контроллер, а реальные действительные значения должны всегда передаваться из контроллера в GUI. Так же это приведет к более сложной логике обработки таких событий в самом контроллере, что для новичков будет существенной проблемой.
Если мы пойдем по простому пути и добавим в элемент управления допустимый диапазон вводимых значений, это частично решит проблему, которую вы описываете. Но это будет как бы заплатка, так как она не решит проблему целиком. Пределы могут изменяться в процессе работы. Кроме того наша цель состоит в том, что бы вся логика проверок максимально была в контроллере и не усложняла GUI и его настройки.
И все же мы уже добавили в наш план:
1. Ввести диапазон допустимых значений в элемент Поле ввода. Это частично решит проблему и оставит легкое использование элемента для новичков.
2. Разработать новые элементы управления с двумя состояниями, желаемым и текущим, которые позволят максимально гибко решать любые задачи. Или каким то образом расширить существующие элементы.
Как решить проблему сейчас? Разместить на экране два элемента, текстовую строку и под ней поле ввода. В текстовой строке отображается значение из контроллера, на основе которого контроллер принимает решения и происходит управление вашим объектом. Поле ввода служит только для изменения этого значения. Изменять ли это значение или нет целиком зависит от логики контроллера. Он может его и не изменить, если оно не соответствует каким то критериям. Как дополнительный бонус, поле ввода можно разместить над LED что бы LED образовывал рамку вокруг поля ввода. Если логика контроллера обнаруживает несоответствие критериям, LED окрашивает рамку в красный цвет. В данном случае опять же только логика контроллера определяет критерии и показывает пользователю что он ввел ошибочные данные.