Оптимальный способ изменения состояния элементов на форме

[KAPACb]

Итак, есть форма.
На ней живописно расположен ворох самых различных элементов - кнопочки, TextBox'ы, Label'ы, списки, RadiButton'ы, CheckBox'ы и проч и проч.
Более того, различные состояния одних элементов влияют на свойства других (например, TextBox1.Visible = CheckBox1.Checked) выстраиваясь местами в длинные цепочки зависимости - чтобы Button1.Enabled было равно True, нужно, чтобы Len(TextBox1.Text) > 0, а чтобы TextBox1.Visible был равен True (чтоб набрать этот самый текст, чтоб заинэйблилась кнопочка), нужно чтобы CheckBox1.Checked было равно False, а чтобы CheckBox1 вообще стало видимым, нужно чтоб RadioButton2.Cheched было равно True и так далее.

Соответственно, возникает некоторая проблема в том, чтобы все эти взаимоусловия правильно работали. Но ещё большая проблема возникает, когда нужндо добавить ещё парочку элементов и поменять схему взаимозависимости.

Перебрав некоторое варианты в поисках оптимального, на данный момент остановился на следующем:

Создаётся отдельный Sub, в котором и записана полностью вся логика взаимоизменений.
В событиях, срабатывание которых должно повлечь за собой некоторые изменения в состояниях элементов, стоит просто вызов этого Sub'а

Плюсы данного решения:
- вся логика собрана в одном месте, легко отслеживать и исправлять ошибки
- любое изменение логики производится 1 раз в одном месте
- при добавлении новых элементов (логика изменение состояния для которых аналогично уже существующему) нужно всего лишь внести маленькие добавления в Sub

Минус у решения только один, но большой - в случаях, когда элементов и взаимозависимостей много (в том числе несвязных друг с другом), а логика громоздка и требует больших вычислений сильно падает эффективность кода - т.к. нужно допустим при изменения состояния CheckBox'а всего лишь изменить Visible одного Lable'а, а фукнция прогоняет полный комплекс вычислений для всех элементов (хотя они в общем-то и не должны меняться).

Вот. Собственно вопрос - существуют ли более эффективные решения ?

[Viper]

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

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

Короче, все надо применять в меру и к месту.