Помогите найти более логичное решение

← →
cosinus (2002-06-26 13:34) [0]

У меня возник такой вопрос, возможно Вам покажется глуповатым, но все же: представте, что у Вас на форме размещено несколько блоков combobox-ов с label-ами, допустим три. Под блоком я подразумеваю, что на одном и том же месте физически находятся несколько combobox-ов один на другом, изменяющих свое свойство visible , в зависимости от сделанного выбора. Естественно, что в каждый отдельно взятый момент visible установлен в true только у одного combobox-а и одного label-а из блока. Вопрос: возможно ли более логичное решение, чем в каждой процедуре, вызываемой тем или иным выбором тупо перебирать все combobox-ы и label-ы и устонавливать их visible в true или false. Их много.
Заранее благодарен, Владислав.

← →
Skier (2002-06-26 13:39) [1]

> cosinus
Т.е. ты хочешь программно менять интерфейс формы ?

Если это так, то видимо кординального улучшения найти
вряд ли удасться, разве только создать класс, который
будет включать Панель и уже на панели combobox и label;
и в этом случае менять visible, только у панели.

← →
Kaban (2002-06-26 13:39) [2]

Можно в run-time сделать массив combobox-ов и label-oв
и обращаться к нужным по индексу

← →
VDen (2002-06-26 13:47) [3]

Можно пользоваться BringToFront и SendToBack. Они меняют порядок.
А еще лучше создать соответствующий класс.

← →
Игорь Шевченко (2002-06-26 13:48) [4]

TFrame может быть ?

← →
Бурундук (2002-06-26 13:59) [5]

2cosinus
Можно просто положить группу компонентов на панель (или групбокс)
и менять видимость только панелей
(как предлагал Skier, но без создания классов).

← →
cosinus (2002-06-26 14:21) [6]

Спасибо всем, но есть маленькое уточнение :один и тот же combobox может появлятся при разных вариантах выбора, то есть они, грубо говоря, микшируются . Например, я выбираю пункт 1 - у меня вылазит cb1,cb4,cb8 ,а при выборе пункта 2 cb1,cb3 и cb7 соответственно. Естественно, подразумевается, что каждый раз будут выбираться одни и теже combobox-ы. Как тут быть?

← →
Kaban (2002-06-26 14:25) [7]

Думаю, проще написать функцию, которая по индексу будет показывать нужные combobox-ы и не мучиться

← →
Skier (2002-06-26 14:31) [8]

> cosinus
Можно "проиндексировать" combobox-ы
с помощью Tag-а и написать функцию
(как предлагает Kaban).

← →
Бурундук (2002-06-26 14:40) [9]

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

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

← →
Бурундук (2002-06-26 14:41) [10]

← →
Наташа (2002-07-01 10:53) [11]

Может проще менять items одного combobox, чем периберать все?
Сделай case по индексу в отдельной функции, которая будет формировать items и и вызывай эту функцию при нажатии своих кнопок с разными индексами. Работает гораздо быстрее и проще добавлять потом новые выборки. Да и памяти лишней не требует.

← →
valery_f (2002-07-01 12:13) [12]

Исходя из моего опыта, большое множество win-контролов, особенно combobox"ов, жутко жрут ресурсы (по хэндлам), и прятанье ненужных контролов дела не спасает, т.к. если контрол хоть раз стал видимым - он завел себе хэндл и держит его до упора (его, конечно, можно уничтожить, но это новые дебри...)

Я бы сделал один label и один combobox, и в зависимости от режима работы (состояния?) заполнял бы их содержимое и по разному реагировал бы на их изменения. Ну, к примеру: вариант 1 - в OnChange combobox"а поставить case по режиму работы, вариант 2 - при входе в какой-то режим переназначать OnChange combobox"а на заготовленные обработчики.

← →
Игорь Шевченко (2002-07-01 12:38) [13]

valery_f (01.07.02 12:13)

Насчет ресурсов - это странно. ComboBox "жрет" от 2-х до 3-х handles, большинство стандартных controls по одному...(не считая ScrollBar"ов). Зато они меньше GDI-ресурсов потребляют :-)))

> вариант 1 - в OnChange combobox"а поставить case по режиму
> работы, вариант 2 - при входе в какой-то режим переназначать
> OnChange combobox"а на заготовленные обработчики.

А в таком случае труднее будет ошибку в программе искать :-)

← →
Opuhshii (2002-07-01 13:30) [14]

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

← →
Толик (2002-07-01 14:17) [15]

Если отвечать на вопрос о наиболее логичном решении, то на мой взгляд всегда следует помнить, что TLabel и TComboBox (и пр.) являются ВИЗУАЛЬНЫМИ компоненами, а значит предназначены ТОЛЬКО для общения с пользователем и не более того. Делать логику программы, основываясь на визуальных компонентах на мой взгляд является грубой ошибкой (сам через это прошёл). Визуальные компоненты должны ТОЛЬКО отображать данные пользователю и/или принимать от него новые данные, а вся обработка данных должна происходить в классах, специально предназначенных для этого, даже, если ради этого придётся продублировать списки (а я так понимаю, что работа ведётся именно со списками). Поэтому для данной задачи достаточно одного "блока" (выражась Вашим языком) компонентов, информация в которых динамически обновляется.

"за" и "против" такого подхода:
- это делать сложнее, да и писанины больше.
+ локализация потенциальных ошибок (а они будут всегда), поэтому проще отлаживать.

А вот решение, как поступать, принимать уже Вам...

Помогите найти более логичное решение Найти похожие ветки