Ситуация следующая: надо унаследоваться от базового фрейма с парой контролов и несколькими методами-свойствами.
Как это сделать в принципе - понятно: наваял в design-time базовый фрейм, засунул в репозиторий, а дальше - New Item и включить inherit
вопрос в следующем: а что будет при командной разработке? Т.е. каким макаром импортировать базовый фрейм с dfm с одной машины на другую (или в систему контроля версий)?
Можно ли как-то унаследоваться от фрейма без возни с ресурс-файлами?

Разобрался, вопрос снят.

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


> Разобрался, вопрос снят.


Из правил форума, пункт 9
"В случае, если поставленная проблема решена, написать в ветке решение — возможно Ваша информация поможет другим участникам. "

> Игорь Шевченко ©   (19.03.08 00:36) [2]

Имхо, Олежка предпочел другой путь:
http://pda.delphimaster.net/?id=1205868370&n=3
Наверно всё-таки не совсем разобрался. Возможно проблема была не в "Наследование фреймов"?

Германн ©   (19.03.08 00:59) [3]

Я вот не всегда понимаю, зачем хранить формы в базе :)

А как же код к ним ?

> Игорь Шевченко ©   (19.03.08 01:54) [4]
>
> Германн ©   (19.03.08 00:59) [3]
>
> Я вот не всегда понимаю, зачем хранить формы в базе :)
>
> А как же код к ним ?
>

Ну, это всё-таки не ко мне.

> Я вот не всегда понимаю, зачем хранить формы в базе :)


Я не храню форму в базе. В базе хранится значение некоего типа данных. Этому типу соответствует собственный PropertyFrame.

> Игорь Шевченко ©   (19.03.08 01:54) [4]

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

Семеныч   (19.03.08 09:39) [7]


> При желании вполне срастается.


В древнем Китае желающим странного отрубали голову. Мудрые были люди, не находишь ?


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


А код тоже писать  и в базе хранить ?

> Игорь Шевченко ©   (19.03.08 09:57) [8]

> В древнем Китае желающим странного отрубали голову. Мудрые были
> люди, не находишь?

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

В чем есть большие сомнения. Понятие "странное" весьма сильно зависит от задачи - а задачи очень разными бывают.

> А код тоже писать  и в базе хранить ?

Еще раз: при желании закомпилированный в EXE код прекрасно срастается с DFM, которая хранится в БД. Иначе и быть не может: если код срастается с DFM, хранящимися в ресурсах программы, то почему бы ему не срастаться с DFM, хранящимися в БД? Не все ли равно, откуда грузить DFM? Коду это, в общем-то, до лампочки - его только надо грамотно написать.

ПыСы
Кстати, ежели заглянуть в ToolsAPI, то там увидим, что file system можно переопределить - и тогда даже саму IDE можно научить работать с формами не из файлов, из БД (да и вообще откуда угодно). Прямо в design-time. Разработчики это предусмотрели - и мне не кажется, что они возжелали странного. Потому что задачи разными бывают.

Семеныч   (19.03.08 10:18) [9]


> при желании закомпилированный в EXE код прекрасно срастается
> с DFM, которая хранится в БД. Иначе и быть не может: если
> код срастается с DFM, хранящимися в ресурсах программы,
> то почему бы ему не срастаться с DFM, хранящимися в БД?
> Не все ли равно, откуда грузить DFM? Коду это, в общем-то,
>  до лампочки - его только надо грамотно написать.


Не...есть еще один момент, что для каждого класса, кроме формы генерируется VMT - и он содержит в себе все published поля, методы и т.д. Грубо говоря, ты не можешь произвольному классу назначить произвольный ресурс,
они должны быть синхронизированы. При компиляции эта синхронизация обеспечивается,
а как ее обеспечить при загрузке из базы - извини, не знаю :)

> Игорь Шевченко ©   (19.03.08 12:50) [10]
> а как ее обеспечить при загрузке из базы - извини, не знаю :)

Очень просто - несколько хранящихся в БД форм имеют один и тот же класс, но могут иметь разное визуальное представление.

Семеныч   (19.03.08 13:02) [11]


> Очень просто - несколько хранящихся в БД форм имеют один
> и тот же класс, но могут иметь разное визуальное представление.
>


Ну это и есть желание странного - одному с рюшечками, другому чтобы edit был справа, третьему чтобы слева и красного цвета :)

> Ну это и есть желание странного - одному с рюшечками, другому
> чтобы edit был справа

Скины. Есть любители этого дела )
Хотя, лично я тоже не разделяю... Если надо работать, то главное -- чтоб ехало, а не шашечки )

> Игорь Шевченко ©   (19.03.08 13:17) [12]

Все намного хитрее. Загруженная форма имеет свой ID и в зависимости от него может меняться логика работы кода. Так что тут далеко не рюшечки.

Семеныч   (19.03.08 13:21) [14]

Ясно. Переложение обнаружения ошибок с этапа компиляции на этап выполнения.

"Бывает нечто, о чем говорят: "смотри, вот это новое"; но это было уже в веках, бывших прежде нас."
Еккл. 1.10

> Игорь Шевченко ©   (19.03.08 13:25) [15]

???
Как понять тебя, Саид? При чем тут переложение обнаружения ошибок?

Ты уверен, что хорошо понял суть подхода?

ПыСы.
Бедняги классики. Если бы они знали, КАК будут пользоваться их высказываниями, они, пожалуй, от оных воздержались бы.

Семеныч   (19.03.08 13:32) [16]


>  При чем тут переложение обнаружения ошибок?


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

Наиболее иллюстирующий пример - это обильное использование типа Variant.

Ну не понимаю я, зачем формы в базе хранить. Формы в EXEшнике или в DLL-ях должны жить, самое им там место. Опять же, дабы синхронизацию выполнял компилятор, а не хитрый код во время выполнения.

> Игорь Шевченко ©   (19.03.08 14:03) [17]

> а во время выполнения вылезают ошибки.

Если руки у программеров заточены криво, то чем виновата архитектура приложения?

> Ну не понимаю я, зачем формы в базе хранить.

Если некто чего-то не понимает, то разве это означает, что это что-то плохое или ненужное?

Семеныч   (19.03.08 15:03) [18]


> Если руки у программеров заточены криво, то чем виновата
> архитектура приложения?


Кроме дополнительного геморроя разработчикам - ничем. А можно пример оправданной необходимости такой архитектуры приложения ?


> Если некто чего-то не понимает, то разве это означает, что
> это что-то плохое или ненужное?


Это означает, что это странное. См. пост о древнем Китае.