обработка свойств элемента GUI для каждого состояния приложения

Question

Я думал о централизации этой функциональности, имея единственный метод, который получает аргумент AppState, и он имеет дело с изменением свойств всех элементов GUI на основе этого аргумента. Каждый раз, когда приложение меняет свое состояние (готово, занято, загрузка частично занята и т. Д.), Эта функция вызывается с соответствующим состоянием (или, возможно, это битовое поле или что-то в этом роде), и оно делает свое волшебство.

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

Есть ли другие способы борьбы с подобными вещами?

Answer 1

Эмр,

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

1. Используйте только одностороннюю связь. Не читайте состояние с органов управления, так как это источник всего зла. Сначала ограничьте число операций чтения свойств, а затем количество записей свойств.

2. Вы должны включить некоторую методологию кэширования. Убедитесь, что кэширование не вводит чтение свойств в основной код.

3. Оставьте диалоговые окна в покое, просто убедитесь, что все диалоговые окна взаимодействуют при открытии и закрытии, а не между ними (столько, сколько вы можете).

4. Внедрение оболочек в наиболее часто используемые элементы управления для обеспечения строгой структуры связи. Не создавайте какие-либо глобальные рамки управления.

5. Не используйте эти идеи, если ваш пользовательский интерфейс не очень сложный. В таком случае использование обычных событий WinForms или JavaScript приведет к уменьшению кода.

6. Чем меньше кода, тем лучше. Не выполняйте рефакторинг, если не потеряете линии.

Удачи!

Answer 2

@ Стефан:

Я думаю, что мы думаем в одном направлении, то есть один фрагмент кода, который изменяет все состояния виджета, и все остальные должны вызывать его, чтобы внести такие изменения. За исключением того, что я представлял прямой вызов метода, в то время как вы представляете события поднятия / захвата. Есть ли преимущество использования событий по сравнению с простым вызовом метода?

Answer 3

Да, это самая трудоемкая часть работы с графическим интерфейсом, чтобы сделать приложение удобным для пользователя. Отключите это, включите это, скройте это, покажите это. Чтобы убедиться, что все элементы управления имеют правильные состояния при вставке / обновлении / удалении / выборе / отмене выбора объектов.

Я думаю, именно здесь вы отличаете хорошего программиста от плохого программиста. У плохого программиста есть активная кнопка «Сохранить», когда нет ничего, чтобы сохранить, хороший программист включает кнопку «сохранить» только тогда, когда есть вещи, которые нужно сохранить (только один пример из многих).

Мне нравится идея обработчика UIControlstate для этой цели.

Me.UIControlStates = UIControlstates.EditMode или что-то в этом роде.

Если у него есть такой объект, он может вызывать события при изменении состояния, и там мы помещаем код.

Sub UIControlStates_StateChanged(sender as object, e as UIControlStateArgs)
   if e.Oldstate=UIControlStates.Edit and e.NewState=UIControlStates.Normal then
      rem Edit was aborted, reset fields
      ResetFields()
   end if
   select case e.NewState
       case UIControlStates.Edit
         Rem enalbe/disable/hide/show, whatever

       Case UIControlStates.Normal
         Rem enalbe/disable/hide/show, whatever
       Case UIControlStates.Busy
         Rem enalbe/disable/hide/show, whatever
       Case Else
         Rem enalbe/disable/hide/show, whatever
   end select
end sub