| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Философия программирования > Техническая сторона интерфейса |
| Автор: UniBomb 3.3.2007, 13:54 |
| Вот интересно, если скажем есть программа которая считывает, обрабатывает выводит большое количество информации с разных источников. Соответсвенно должно быть море едитов, лейблов, баттонов и прочих фенек. Лично у меня общее количество их достигает около полутора сотен. Так как же всё таки их грамотнее и удобнее создавать? Пока я знаю два способа - это в момент создания натыкать все элементы на форму и потом писать длинные коды для работы с каждым элементом поотдельности. Второй способ это создание массива элементов и пототот в цикле всех их и отображать. Но и этот способ мне не особо нравится... Есть ли другие методы? |
| Автор: skyboy 3.3.2007, 14:06 |
ясень пень! в первую очередь, есть другие методы ввода, кроме полей для ручного набора. можно вводить график какой-то зависимости, просто рисуя мышкой. можно определять ключевые точки, а потом сплайновой интерполяцией получать промежуточные данные. можно, в конце концов, заменить гору edit'ов для однотипных данных одним StringGrid'om. Можно... Кстати, а какая задача? какие данные? почему их так много? |
| Автор: UniBomb 3.3.2007, 14:20 |
| skyboy, Ну если конкретные пример - программа опрашивает хренову тучу датчиков, выводит предварительную инфу о них, расчитывает передаваемые значение, рачитывает обсолютные и относительные погрешности. В программу вводятся значения текущей погоды (давление, влажность, тепература и т.д.), должны вводится результаты внешнего осмотра и опробывания по нескольки пороговым значениям и т.д. (если ещё более конкретно - программа автоматизации поверки газосигнализаторов, причём если в газосигнализаторе не пердусмотрена опция интерфейса общения с компом, то абсолютно все данные вводятся ручками). А СтрингГрид мне не нравится - что то он больно кривовато выглядит(( |
| Автор: Sartorius 3.3.2007, 14:26 |
| Для ввода действительно большого набора данных обычно используются заранее подготовленные файлы. Это и проще и надежней. |
| Автор: UniBomb 3.3.2007, 14:31 |
| Sartorius, Дык, а если данные - это отображение текущих значений чего либо? Т.е. динамически изменяющихся и в зависимости от этих данных надо делоть что то другое? (Хм... надеюсь понятно)) |
| Автор: Sartorius 3.3.2007, 14:40 | ||
| Я бы предложил сделать так: - Все данные, которые меняются редко прописывать в отдельном файле и сделать возможой загрузку его в момент работы проги
Вот это плохо. Если есть время - то может быть все таки сделать все обстоятельно - спроектировать программно-аппаратный комплекс. Подключить все приборы к АЦП и снимать все параметры без участия человека. |
| Автор: UniBomb 3.3.2007, 15:10 | ||||||||||
Есть данные, которые меняются всего один раз - для формирования отчёта, для них выполнены значения "по умолчанию". Но тем не менее количество рющек для отображения/изменения меньше не становится...
Вот тут уже ничего селать низя. Т.к. приборы уже готовые, с тремя модификациями - с интерфесом(можно подключить к компу), с релейными выходами и с транзиторным выходом (например с открытым коллектором). Соответсвенно и методика поверки меняется. НО! независимо от модификации необходимо сохранять все показания, все погрешности и т.д.
в виде чисел))
Если бы было можно, то эти датчики стоили бы кучу денег. Ведь необходимо ещё ставить сенсор влажности, калибровка которого требует уйму времени и дорогого оборудования... ну и т.д. в том же духе...
Ну например у тебя есть таблица 12х6 и тебе надо удалить одну строку. Все шесть значений столбцов ты должен гдето сохранить, все ниже лежащие строки сдвинуть вверх, потом если необходимо опять показать эту строку, то нужно все строки от нужной сдвинуть вниз, потом вставить сохранённые значения и так для всех строк. С эдитами как мне кажется проще - просто поставить ивизибль, поотом лёгким движением кода сдвигать... И вообще, давайте не переходить на конкретные примеры)) Вот скажем задача - отобразить матрицу 25х35 едитов (для примера), как вы это сделаете? |
| Автор: skyboy 3.3.2007, 15:22 | ||
если такая ситуация возникает, лучше просто скрывать строку. данные могут быть сгруппированы по каким-либо обобщающим признакам? если да - разобью на группы(при помощи закладок, панелей, даже разных форм); если нет - воспользуюсь таблицей. а какие данные в этих edit'ах? например, если 0/1, то лучше сделать таблицу checkbox'ов. если фиксированный набор - таблица выпадающих списков(combobox'ов). я ведь все ещё не знаю, какими данными ты оперируешь. и - на каком языке собираешься реализовывать программу. |
| Автор: UniBomb 3.3.2007, 15:29 | ||||
| skyboy, Я имел в виду несколько другое - вручную понатыкаеш или сделаеш что то типа
или сделаеш дллку, в которй всё это дело укажеш...
У меня примерно так и есть)) |
| Автор: skyboy 3.3.2007, 15:43 | ||||
насколько "примерно"?
не знаю. насколько динамичен этот набор? как часто что-то скрывается или отображается? а смысл? настолько все часто меняется, или что? повторю вопрос:
|
| Автор: UniBomb 3.3.2007, 15:52 | ||||
| skyboy, В приципе да - для вывода концентрации, для вывода серийнико, для вывода погрешностей, для ввода предварительного опробывания и т.д.
Ну смысл что бы описывать каждые элемент не в теле программы а в библиотеке, дабы визуальнее код был меньше.
Весь набор мимеет постоянное количество, 1/3 элементов изменяется один раз, скрывается всё простым инвизиблём... Чуть позже выложу скрины... |
| Автор: skyboy 3.3.2007, 15:56 | ||||
я не про это. насколько часто возникает потребность что-то скрывать?
тогда и правда - лучше сгруппировать. если "групп данных" много - используй представление в виде дерева(назвал бы язык разработки - указал бы, куда копать); если групп несколько - лучше закладки.
разбивай на функции код. dll не для "визуального уменьшения кода", у них - другое назначение. |
| Автор: UniBomb 3.3.2007, 16:38 |
| Вот примерный вид программы: |