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

Question

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

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

Любые другие способы борьбы с такими вещами?

Answer 1

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

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

Мне нравится идея 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 

Answer 2

@Stefan:

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

Answer 3

Emrah,

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

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

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

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

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

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

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

Удачи вам!