2013-04-24 4 views
1

Я использую текст, чтобы определить состояние кнопки и хочу знать, принято ли вообще?Можно ли использовать текст на кнопке, чтобы определить текущее состояние?

У меня есть представление в формате datagrid со списком элементов и кнопкой «Готово». Когда пользователь нажимает кнопку «Готово», ячейка подсвечивается зеленым цветом, чтобы отметить, что она выполнена.

Затем я меняю текст кнопки на «Отменить». Поэтому всякий раз, когда пользователь прокручивает «зеленую» ячейку, текст кнопки изменяется на «Отменить».

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

Это нормально? Или я должен использовать какой-то монитор состояния?

ответ

0

Я думаю, что это едва приемлемо, но все еще плохо.

Сохранение статуса в переменной не намного больше усилий и сделает код более ремонтопригодным (не смешивайте обработку и графический интерфейс).

Когда вы как-то меняете текст кнопки, вам также нужно будет настроить проверку.

Кроме того, это упрощает обновление GUI (нескольких потоков и т.п.).

+0

Спасибо! Попробуй и избегай этого. Мой текущий код выполняется так, но если у меня есть время, я его изменю. Вы могли бы предложить создать enum или boolean для проверки состояния? –

+0

Если у вас есть только два возможных состояния, используйте boolean. Создание перечисления здесь не требуется. Если у вас более двух, используйте перечисление. – Drasive

0

Образец Я пользуюсь во многих случаях частными полями, указывающими логическое состояние элементов управления и свойствами, которые приводят к тому, что свойства самих элементов управления обновляются своевременно. Если есть одна точка взаимодействия со свойствами самих элементов управления и при условии, что поля всегда представляют допустимое состояние, то код, не относящийся к UI-потоку, может изменять состояние элементов управления без необходимости синхронизации с потоком пользовательского интерфейса; он просто должен убедиться, что есть запрос, ожидающий обновления элементов управления, когда это будет удобно.

Хотя в вашем конкретном примере не затрагиваются какие-либо проблемы с потоками, и, следовательно, на самом деле не выгодно использовать потоки, предоставляемые путем разделения состояния управления из логического состояния, используя тот же шаблон для случаев, требующих многопоточной поддержки, для случаев, которые не уменьшают количество различных шаблонов, с которыми приходится иметь дело. Кроме того, если вы используете свои собственные поля для представления различных состояний, которые могут иметь элементы управления, вы можете убедиться, что они никогда не будут представлять собой неоднозначное или недопустимое состояние. Например, если фрагмент кода задал кнопку «UNDO», а не «Undo», другой код мог бы решить, что «это не« Undo », поэтому он должен сохранять», некоторые могут решить, что «это isn ' t Save, поэтому он должен отменить «, некоторые могут ничего не делать, а некоторые могут скандировать. Кроме того, может быть сложно добавить какие-либо дополнительные состояния или указания. Например, можно добавить к кнопке «Отменить» указание того, что будет отменено. Если вы используете поля для отслеживания состояний, можно добавить такую ​​функциональность, не нарушая поля, которое отличает «сохранение» и «отмена»; либо добавьте другое поле, чтобы отслеживать, какая конкретная операция должна быть указана, когда отображается кнопка отмены, или же, чтобы подпрограмма «текст кнопки обновления» использовала существующие поля, чтобы определить это.

Смежные вопросы