Есть ли визуальное наследование форм в lazarus?

[alexs]

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

это ошибка проектирования приложения если у тебя куча одинаковых форм с одними и темиже элемиентами ввода данных. Обычно народ даже на слышал о таком понятии как нормализация данных - отсюда и вытекает куча одинаковых форм для ввода чёрти-чего, а затем возникают вопросы о бесполезности FK в данных

[Attid]

Короче говоря, все это подходит только для тех проектов, которые в принципе не планируется поддерживать...

а вот хотелось бы услышать разьеснение, почему вы так считаете ?

Именно из-за отсутствия визуального наследования я до сих пор не использую Лазарус. Лично мне для моих проектов это сэкономило бы кучу времени.

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

ну и в конце если если останавливает только это то можно обойтись костыликами ну или добавить код в лазарь, в МСЕ ведь есть перенести можно при желании.

[debi12345]

это ошибка проектирования приложения если у тебя куча одинаковых форм с одними и темиже элемиентами ввода данных. Обычно народ даже на слышал о таком понятии как нормализация данных - отсюда и вытекает куча одинаковых форм для ввода чёрти-чего, а затем возникают вопросы о бесполезности FK в данных

Какая еще "нормализация" ??? Она-то тут причем, братья-россияне ?
Программный комплекс из АРМ бухгалтера, АРМ охранника,.. АРМ сантехника. У всей сотни АРМ одинаковые кнопки, одинаковый набор состояний, одинаковые сообщения, но разные наборы данных.
А про FK не напоминайте - злой становлюсь ;( Только сегодня парочку злобных integerity-триггеров прибил...

Признайтесь, что смирились с писаниной ненужного кода, а теперь сами себя убеждаете, что это нормально. Лучше бы пинали команду лазаруса.

Про наследование кода :

В Delphi это решалось без наследования с помощью DataModule...

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

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

[Tiger]

это ошибка проектирования приложения если у тебя куча одинаковых форм с одними и темиже элемиентами ввода данных. Обычно народ даже на слышал о таком понятии как нормализация данных - отсюда и вытекает куча одинаковых форм для ввода чёрти-чего, а затем возникают вопросы о бесполезности FK в данных

Смотри случай: у меня в программе есть порядка пяти разных реестров для разных типов документов! Но для всех них характерны операции: ДОБАВИТЬ, ИЗМЕНИТЬ, УДАЛИТЬ, РАСПЕЧАТАТЬ, НАЙТИ ЗАПИСЬ ПО СТРОКЕ ТЕКСТА, ЭКСПОРТ В "MS|OPEN ОФИС", "ОТОБРАТЬ ПО КРИТЕРИЮ" - как минимум!
Зачем мне тратить время на рисование ПЯТИ разных окошек с кучей одних и тех же элементов на тех же местах , и писать обработчики во всех пяти для каждой формы, если я могу нарисовать только одно с DBGridом, навигатором для понта, и семью кнопочками снизу - как предка для них всех, сделав там же функции поиска и экспорта в "офис", а в порожденных от него "визуально" я только напишу коды обработчиков по нажатию на оставшиеся кнопки и добавлю кой-какие специфические контролы?
Причем тут избыточность и нормализация данных? Мы, наверно, про разное говорим?

"Программный комплекс из АРМ бухгалтера, АРМ охранника,.. АРМ сантехника. У всей сотни АРМ одинаковые кнопки, одинаковый набор состояний, одинаковые сообщения" - не нравиться мне эта идея, идея наследования уязвимостей от сантехника до бухгалтера.
одинаковые кнопки - одинаковые проф функции, удивлен

И какой смысл рисовать под разные АРМы одного программного комплекса разные во всём окна? Нет, конечно совсем все окна одинаковые быть не могут - это и ежу понятно, но, вот мой пример выше: управляющие элементы будут одни и те же: Таблица, и ряд кнопок под, над, сбоку от нее - кому как нравится! со своими общими от предка текстами-надписями, или специфическими. В потомках же уже можно дорисовывать очень специфичные для формы элементы - этого, вроде, никто не запрещает? - это как раз и дает массу удобств - использовать порождение/наследование не только в коде, но и в дизайне - то, чего так не хватает в Лазаре.

[Портос]

4. Посмотрите мой вышестоящий пост насчёт правильного проектирования систем - почитайте буквари.
провокация удалась - развели флейм - щас нас отсюда попрут

Какие буквари, господин хороший? Ссылку-то дайте! Поучиться страсть как люблю...

Кстати, господа! Спешу пофлеймить, пока модер не забанил. Нашел я пути неведомые, кроссплатформенные. Но эффективныя!..
Короче, так. Не заморачиваясь, пишем на Дельфи (я - на D7). А полученное приложение крутим хошь под виндой, хошь под Linux/wine. Дешево и сердито!

[debi12345]

под Linux/wine.

Все равно не то. Для адаптации написанных Вынь32-приложений нормалек - сам TitalCommander таким образом использую.
Но для новых Линукс-приложений - не вижу смысла. В первую очередь - проблемы для работы на низкоуровнем аппаратном уровне. Вторая - печать. Третья - различные системы секьюрити типа "security tokens".

[tria]

Внесу немного сумятицы....
Наследование форм есть, и я им пользуюсь. Криво работает, но работает.
На счет "никто не пишет на Лазаре" - можете глянуть на мой проект www.tria.biz.ua
В нем в редакторе структуры формы корректировки справочников, документов и регистров унаследованы от форм перечня.

В коде просто указываем:
TfmEdDoc = class(TfmEditPerechn)
и, на сколько я помню, надо бы закрыть-открыть фрму, а мож и Лазаря...
давно это было, уже не помню точно все что.

[alexs]

Смотри случай: у меня в программе есть порядка пяти разных реестров для разных типов документов! Но для всех них характерны операции: ДОБАВИТЬ, ИЗМЕНИТЬ, УДАЛИТЬ, РАСПЕЧАТАТЬ, НАЙТИ ЗАПИСЬ ПО СТРОКЕ ТЕКСТА, ЭКСПОРТ В "MS|OPEN ОФИС", "ОТОБРАТЬ ПО КРИТЕРИЮ" - как минимум!

я не изобретаю в очереднйо раз генераторы отчётов - мне хватает fastReport-а
а для ввода первичных данных использовать dbgrid - уж нет - спасибо - мне догроги мои заказчики
и где тут место визуальному наследованию?

А полученное приложение крутим хошь под виндой, хошь под Linux/wine

всё хорошо - я тоже так работаю - но всёж родные линуксовые притложения работают стабильней и быстрее - в вине есть глюки

[debi12345]

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

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

и где тут место визуальному наследованию?

Да всюду ! Если голое отображение еще можно как-то заменить генерацией отчета ( который то же бы не мешало визуально наследовать - при большом количестве однотипных ! ), то ввод/редактирование - никак без форм.

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

[alexs]

О чем спорим, народ

в споре рождается истина

Пинайте команду лазаруса

а вот это одобрям
хотя можно (и нужно) и самим что нибудь привносить

[Tiger]

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

А это тут причем? Это про нормализацию данных?
Хотя, такое иногда можно и даже нужно.
Например, содержание все той же счет-фактуры или просто счета.

и где тут место визуальному наследованию?

Перечитай и осмысли еще раз мой пост ранее, целиком! и конец поста особенно, где полужирным выделено! Я там, по-моему, даже повторяюсь