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

Эмра,

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

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

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

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

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

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

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

Удачи!

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

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

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

@Стефан:

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