| olegenty |
| Отправлено: 07.11.2006, 09:23 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
на данный момент заканчиваю доработку универсальной формы редактирования записи.
в ней можно редактировать
1. Строки
2. Текст (многострочный)
3. Целые значения
4. Значения с плавающей точкой
5. Значения логического типа
6. Значения, выбираемые из списка
7. Путь к файлу
8. Дату
9. Время
10. Дату и время
11. Некие "собственные" типы со специфичным отображением и правилами редактирования
Может ещё какой тип не учёл? Кто писал универсальные редакторы — а что вы обычно редактируете?
|
|
| gvg |
| Отправлено: 07.11.2006, 11:20 |
|
Машинист паровоза
Группа: Участник
Сообщений: 222
|
Давно использую подобную реализацию потомка CustomMaskEdit. У меня еще выбор/редактирование каталога. |
|
| olegenty |
| Отправлено: 07.11.2006, 11:25 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
угу точно.
не, это не поле, это динамически строящаяся форма. например: на входе запись из какого-нибудь наследника TDataSet (хотя, это не обязательно), а на выходе — модальная форма редактирования этой записи.
|
|
| AVC |
| Отправлено: 07.11.2006, 11:51 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
У меня еще есть
выбор из произвольного запроса одной строки (пришлось повозиться с правилами для отображения)
выбор множества строк из произвольного запроса (возврат — список PK)
и значения из списка реализовано в двух ипостасях
просто список возможных значений с возможностью ввода своего
выбор из маленькой текстовой таблицы, здесь выбор фиксирован.
В тех местах, где выбирается не одно значение (выбор записи или строки из таблицы) движок автоматом меняет все одноименные значения редактируемой записи.
PS.
Естественно, что тексты запросов, списки значений и текстовые таблицы являются частью описания поля и хранятся снаружи программы (обычно на сервере БД). Перечень редактируемых полей и тип редактора для каждого поля там же
PPS.
Забыл. Из последних доработок. Сделал пару информационных полей (типа лабел).
Кнопки, которые умеют вызывать и исполнять скрипт с сервера бд.
PPPS
| QUOTE | не, это не поле, это динамически строящаяся форма. например: на входе запись из какого-нибудь наследника TDataSet (хотя, это не обязательно), а на выходе — модальная форма редактирования этой записи.
|
Аналогично. Только не запись наследника DataSet а некая виртуальная запись, но в ней много общего с DataSet. На выходе true — все ок, false — пользователь нажал отменить и правильно заполнены поля виртуальной записи.
Подобная реализация редакторов полей есть и для использования прямо внутри DBGrid'а. |
|
| olegenty |
| Отправлено: 07.11.2006, 13:03 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
да, работу с выбором из набора данных, получаемого запросом я туда тоже перенесу из другого/других мест (как раз — одной записи и группы записей). всё так. понятное дело, что пользуюсь также виртуальной записью своего собственного типа — CFields, который суть потомок от map < AnsiString, Variant>, точнее, конкретная специализация шаблона
| CODE |
template <class CKey, class CValue> class CFields: private map<CKey, CValue>
{
...
};
|
|
|
| AVC |
| Отправлено: 07.11.2006, 13:35 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
У меня древняя разработка. На базе TList'ов. Поле начиналось то же как набор пар name, value но быстро разрослось до... Да и одноименные поля у меня управляемо разрешены и иногда я этим пользуюсь. |
|
| olegenty |
| Отправлено: 07.11.2006, 14:23 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
одноимённые поля разруливаются на уровне класса CTable, который суть специализация
| CODE |
template <class CFields> class CTable: private vector<CFields>
{
};
|
PS — вообще говоря это именно ты меня сподвиг всей этой хренью заниматься, до этого я писал намного хуже, хотя под рукой было всё, чтобы писать так.
P.P.S. и это постепенно превращается в стандарт моего подразделения. не очень резко — ядро рождается в муках, но тем не менее двое уже освоили и перешли на работу с моим модульным ядром. поэтому следующим шагом явилась тотальная универсализация. чуть позже всё, написанное моим подразделением, будет универсальным и легко сопровождаемым. надеюсь.
|
|
| AVC |
| Отправлено: 07.11.2006, 14:55 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE (olegenty @ 07.11.2006, 14:23) | | будет универсальным и легко сопровождаемым. надеюсь. |
Так и будет. А как легко вносить изменения типа новый отчет (выборка) или дополнительные условия выборки ... Я уже забыл когда по таким мелочам лазил в исходник — все в описаловке на сервере.
Еще одна, даже можно сказать основная, роль такой формы — заполнение параметров запроса, скрипта и т.д.
Кстати, из идей, help для таких универсальных форм это один из параметров описания и хранится рядом на сервере. |
|
| olegenty |
| Отправлено: 07.11.2006, 15:02 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Есс-но. Вот уже сейчас УЖАС — представляю, сколько времени уйдёт на документирование. 
|
|
