Множество форм для работы с данными. Как лучше реализовать?

[Leonius_Bad]

Здравствуйте.
Имеется программа, которая в БД хранит множество сущностей/объектов(не знаю, как верно тут назвать). У каждой из которых есть свой набор полей. Некоторые поля, например, имя\название, повторяются, другие же уникальны.
Для каждой сущности юзеру должен быть предоставлен интерфейс для редактирования существующего\добавления нового экземпляра (в идеале именно один интерфейс для обоих действий).
Т.к. набор полей у сущностей разный, то для каждой юзер должен видеть свою форму со своими элементами и заголовками их поясняющими.

Внимание, вопрос. Как лучше\грамотней\правильней реализовать создание этого множества форм? Сущностей предполагается около 10, в дальнейшем возможно увеличение.
Сейчас я вижу такие варианты.
1. Полностью визуально-статически. Создаем в Лазарусе форму, кидаем на нее элементы, располагаем как нужно, а дальше уже вешаем обработчики.
Так хочется использовать именно этот вариант. Он выглядит проще. Но 10-ок форм, которые по принципу работы похожи...не есть круто, да? Зато удобно в какой-то мере.

2. Полностью кодом-динамически. Используем для всех сущностей ОДНУ форму, заполняя ее программно созданными компонентами.
Выйдет дольше, чем первый вариант, т.к. компоненты придется подгонять и создавать. А потом еще и заполнять и вешать обработчики. Зато всего одна форма. И хардкор.

3. Используем вкладки. Снова используем только одну форму, на ней создаем кучу вкладок (для каждой сущности по одной) и скрываем их все. В процессе работы делаем видимой необходимую вкладку.
Казалось бы золотая середина, но выглядит как дикий костыль. К тому же, не будет ли куча невидимых вкладок жрать лишнюю память? Ведь фактически-то они есть.

Возможно, имеются и другие варианты решения. Если да, то хотелось бы их услышать.

[Снег Север]

Что значит "жрать память"? Вы на 386-м собираетесь запускать с 640К? Полсотни форм съест у вас ну, скажем, полторы сотни мегабайт памяти. Это сущие пустяки даже для поганого офисного компа.

[Sharfik]

Нужно понять, что за данные пользователь там видит и редактирует.
Для себя я кажется все перечисленные этапы пробовал. На картинке интерфейс редактора БД. Общая форма, но сами вкладки это отдельные формы которые вставляются в PageControl. Минус тут - из dll не получится внедрить форму. Сам компонент, который отрисовывает поля разработан с нуля. Потому что кучу функций мне полезных и нужных не найти в обычных инспекторах объектов(например кнопка "Найти в интернет"). Обработку загрузки в этот компонент можно, при желании сделать динамической(на что я скоро перейду наверно), а отдельные поля ручками реализовать(если где то нужен вызов крутого диалога).
Но сам редактор и архитектура работы логики загрузки, обработки занимают кучу времени на обкатке и проработке.

[Leonius_Bad]

Что значит "жрать память"? Вы на 386-м собираетесь запускать с 640К? Полсотни форм съест у вас ну, скажем, полторы сотни мегабайт памяти. Это сущие пустяки даже для поганого офисного компа.

Полсотни мегабайт? Ну вот и сравните эти полсотни с 5-15 Мб. Пусть для юзера результат и не очевиден. Но разница значительна: оперативную память нужно беречь всегда. Разве нет?
К тому же, про память я говорил в случае с кучей вкладок, Вы же, как будто кучу форм имеет ввиду. Поправьте, если я не прав: куча скрытых, но уже созданных, вкладок будет жрать куда больше, чем куча форм, которые еще по факту не созданы. Так?
Если Вы таки про множество именно форм, то я согласен.

Нужно понять, что за данные пользователь там видит и редактирует.

Программа для работы с книгами. Аля Сам себе библиотекарь. Есть книги, у них есть авторы, издательства, описания, жанры, год написания и т.п.. В свою очередь у авторов, издательств тоже есть поля типа имени, года рождения\основания, веб-сайта и прочего. И еще несколько подобных сущностей.
Как лучше поступить здесь?

Неплохая у Вас программа=) Т.е. вкладки Свойства, состав, монитор данных и обе левые вкладки это PageControl? Ну, тут немного иная логика. Они у вас необходимы всегда, т.е. у любого выбранного объекта, как я понимаю. У меня же в таком случае вкладка будет содержать лишь информацию для одного объекта.

Я пока что придерживаюсь такого мнения.
Раз есть возможность удобно и наглядно клепать формы визуально, то нужно задействовать. Тем более, что не созданная форма никак и не мешается, размер исходного файла не особо увеличивается при большом их кол-ве да и не так он и важен в наши дни.
Создание через код же вижу необходимым, только когда конечное количество и вид полей на той или иной форме неизвестно. Например, когда пользователь имеет возможность добавлять новые поля для ввода в процессе работы программы и т.п. Не мой случай, у меня кол-во и вид полей для каждого объекта известны до запуска программы.
Идея с вкладками мне все же не нравится. Пусть и не существенно оно съест оперативной памяти, пусть даже вообще не съест. Но невидимая куча вкладок, которая постоянно присутствует на форме - нехорошо, разве нет?

[Mikhail]

Поправьте, если я не прав: куча скрытых, но уже созданных, вкладок будет жрать куда больше, чем куча форм, которые еще по факту не созданы. Так?

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

Насчет памяти, компонент типа TLabel, TEdit, TCombobox и т.п. занимают, примерно 1кб памяти максимум (без учета содержащихся данных), т.е. форма из 30 - 40 элементов (а это много) будет занимать, максимум 100 - 150 кб.

[Leonius_Bad]

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

С фреймами толком не работал никогда. Но вот эту схему попробую, спасибо.
Позвольте только уточню, верно ли я понял Ваше предложение.
Создаем вместо форм фреймы для каждого объекта (Файл-Создать-Фрэйм). Оформляем их как надо, прописывает обработку и т.п. Затем при необходимости программно вызываем конструктор нужно фрейма и паркуем его в нужной форме (делаем форму родителем и владельцем). Как-то так?
При этом, при запуске программы фреймы не будут автоматически созданы (в меню, где задаются автоматически создаваемые формы, фреймов нет вообще) до непосредственно вызова конструктора или визуального расположения фрейма на форме, верно?

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

Насчет памяти, компонент типа TLabel, TEdit, TCombobox и т.п. занимают, примерно 1кб памяти максимум (без учета содержащихся данных), т.е. форма из 30 - 40 элементов (а это много) будет занимать, максимум 100 - 150 кб.

И с фреймами, как понимаю, тоже самое. Ну, не страшно вовсе. Но код(динамическое создание форм и тп, вариант №2), наверняка занял бы меньше?
Но тут уже погоня за мелочью. Вопрос так, чисто для расширения кругозора:)

[Mikhail]

Создаем вместо форм фреймы для каждого объекта (Файл-Создать-Фрэйм). Оформляем их как надо, прописывает обработку и т.п. Затем при необходимости программно вызываем конструктор нужно фрейма и паркуем его в нужной форме (делаем форму родителем и владельцем). Как-то так?

Да.

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

Да.
Обратите внимание, что закрыть фрейм нельзя, у него нет метода Сlose, используйте соответствующие методы контейнера в который Вы поместите фрейм (свойство Parent, например).
Кстати, можно использовать наследование (правда в Лазарус я не пробовал), например можно создать наследника TCustomFrame для унификации работы с Вашими фреймами.

Но код(динамическое создание форм и тп, вариант №2), наверняка занял бы меньше?

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

[Leonius_Bad]

Обратите внимание, что закрыть фрейм нельзя, у него нет метода Сlose, используйте соответствующие методы контейнера в который Вы поместите фрейм (свойство Parent, например).

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

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

Вот этим сообщением вообще всё разъяснили Спасибо!
Исходя из этого и буду плясать. Пока что мне действительно гораздо быстрей накидать формы визуально, точней, теперь уже фреймы.

[Mikhail]

Т.е. когда фрейм отработал, он останется в памяти до закрытия программы?

Нет, разумеется, если Вы его уничтожите с помощью Free или контейнер в котором он расположен (при условии что Owner при создании фрейма <> nil)

Кстати, Close не выгружает форму, как правило, а лишь скрывает ее.

[Leonius_Bad]

Нет, разумеется, если Вы его уничтожите с помощью Free или контейнер в котором он расположен (при условии что Owner при создании фрейма <> nil)

Кстати, Close не выгружает форму, как правило, а лишь скрывает ее.

Хорошо. Понял. Еще раз спасибо=) Буду пробовать.

А про форму.
Даже если в событии закрытия прописать: CloseAction:=caFree;
Тоже не будет выгружена? Там есть еще caHide. В моем представлении, при caFree она как раз должна была бы убиться.

[Mikhail]

Даже если в событии закрытия прописать: CloseAction:=caFree;
Тоже не будет выгружена?

Будет, но по умолчанию для всех форм, кроме главной, все же установлено caHide.

[Sharfik]

Неплохая у Вас программа=) Т.е. вкладки Свойства, состав, монитор данных и обе левые вкладки это PageControl? Ну, тут немного иная логика. Они у вас необходимы всегда, т.е. у любого выбранного объекта, как я понимаю. У меня же в таком случае вкладка будет содержать лишь информацию для одного объекта.

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

[Снег Север]

Но разница значительна: оперативную память нужно беречь всегда. Разве нет?

Нет. Беречь надо свой труд. И я писал не полсотни, а полторы сотни. Из личного опыта, правда, на Делфи. Для программы со множеством форм рассчитанной на работу, фактически, в монопольном режиме, это совершенно нормально. Беречь память надо начинать, если программа жрет больше половины гигабайта.

[zub]

>>Нет. Беречь надо свой труд. И я писал не полсотни, а полторы сотни. Из личного опыта, правда, на Делфи
Наформошлепать полторы сотни форм? терпения вам не занимать, меня и на одну нехватает... Я понимаю десяток какихнибудь важных с хитрым поведением, для остальных - какойнить [s ]механизм[/s]велосипед автогенерации.

[Снег Север]

Частично была и автогенерация. Но примерно половина форм внедрялась в другие формы или показывалась из dll, из многочисленных плагинов.