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

[Портос]

Собственно, subj.

Фреймов тута нет - это уже понятно.
Скажите господа, и вы действительно работаете на этом продукте? Или просто притворяетесь?
Я попытался создать простейшее приложение с гридом, и мне это удалось! Правда, я был поражен обилием ругани со стороны Лазаруса.
Ругань эта прекращается после выгрузки/загрузки проекта. Возобновляется при малейших изменениях в TSQLQuery. TSQLQuery не понимает, что в MS SQL - stored procedure может возвращать SELECT и не позволяет изменить свойство StatementType. Эта шибко умная компонента самостоятельно устанавливает это свойство и не дает мне получить данные...

При старте Лазарус жалуецца, что не может найти system.ppu и тыкает меня в какой-то fpc.cfg. Я скачал, инсталлировал - какого хрена он с меня еще требовает? (ОС - Win XP).

У меня сжимается грудь при виде всей этой убогости...
Оно понятно - чего от самоделки бесплатной хотеть...
Может, слово какое петушиное знаете?
Извините, если что не так.

[alexs]

1. убогость это MS SQL
2. читать документацию по fpc
3. если всё так плохо - зачем на него вобще смотриш - он бесплатен, на нём никто не заставляет никого работать
4. визуальное наследование форм - это, помягче сказать... не самая нужная техника - просто лучше проработай свой проект - потребность отпадёт

[debi12345]

4. визуальное наследование форм - это, помягче сказать... не самая нужная техника

Шутка ???

[alexs]

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

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

в принципе если у тебя несколько штух одинкаовых интерфейсов то проще обычно их свести в один - иначе что-то не так у тебя было на этапе проектирования. Не надо довать оператору 100 и 1 способ сделать одну и туже операцию.

Фреймы - это более полезная штука, вот их действительно не очень хватает - но это я обычно решаю не визуальным созданием контейнера на базе TPanel и в onCreate формы ложу куда нужно.

[Портос]

1. убогость это MS SQL
2. читать документацию по fpc
3. если всё так плохо - зачем на него вобще смотриш - он бесплатен, на нём никто не заставляет никого работать
4. визуальное наследование форм - это, помягче сказать... не самая нужная техника - просто лучше проработай свой проект - потребность отпадёт

1. Тут Вы, батенька, погорячились... Если еще скажете, что и Oracle - убогость, то нигилист Вы первостатейный. Эдак батенька, в Базаровы пойдете, с Верой Павловной сны считать...
2. А смысл?
3. Тщусь возможностей разработки кроссплатформенных приложений. Бесплатность - не цель, вот и заглянул сюда. Вообще, с кроссплатформенностью хреновато как-то...
4. Если бы я не использовал визуального наследования форм и фреймов, то время разработки бы увеличилось раза в полтора за счет тупого копирования. А сопровождение - еще более. Подозреваю батенька, что не рубите вы в колбасных обрезках...
Ну так я понимаю, и визуального наследования тут нету. Грустно, девушки...
Вы не подумайте, что Lazarus - какое-то особенное убожество. К примеру, Java местами - просто хрен на палке какой-то. И тоже наследований нету...
А Lazarus - он ничего... Не каждый сможет почти пустую форму на 11 мег сгенерить, всего за пять минут... ))

[debi12345]

в принципе если у тебя несколько штух одинкаовых интерфейсов то проще обычно их свести в один - иначе что-то не так у тебя было на этапе проектирования.

Удобство не столько в повторении внешнего вида, сколько в наследовании кода операций, общих на всех формах. А отличающиеся методы просто переопределяешь.

Не надо давать оператору 100 и 1 способ сделать одну и туже операцию.

Почему одну и ту же ? Например, в MSEgui туториале "persons" наследование форм используется для построения форм редактирования планет, стран, континентов,.. . А код отображения и записи в БД, а также разрешения кнопок - был описан однажды, в generic-форме. Меньше кода = меньше ошибок = меньше отладки =...

[alexs]

1. Тут Вы, батенька, погорячились... Если еще скажете, что и Oracle - убогость, то нигилист Вы первостатейный. Эдак батенька, в Базаровы пойдете, с Верой Павловной сны считать...

не сравнивай хорошую rdbms с неизвесно чем - когда версионность в MS появилась? (подсказка - это событие случилось как раз после открытия кодов interbase)
2. - в отличии от других продуктов - в fpc очень хорошая документация.
3. Если не пользоваться функциями винды, то кросплатформенность отличная - проверил на собственном опыте.
4. Посмотрите мой вышестоящий пост насчёт правильного проектирования систем - почитайте буквари.

провокация удалась - развели флейм - щас нас отсюда попрут

[shade]

Разбавим флейм:

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

Я вообще в первые слышу про визуальное наследование... и никогда не испытывал трудностей с его отсутствием. Может кто-нибудь объяснит что-к-чему, с чем едят, когда и где появилось (в Delphi 6 не нашел - не там искал?)?

Удобство не столько в повторении внешнего вида, сколько в наследовании кода операций, общих на всех формах. А отличающиеся методы просто переопределяешь.

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

Вот в Double Commander используется наследование форм - определена абстрактная форма TfrmLng (которая определяет единственную абстрактную процедуру LoadLng и событие OnCreate с вызовом LoadLng), а от нее наследуют все остальные формы и переопределяют LoadLng - IMHO гемор (из-за которого у меня время от времени вылетает lazarus...) - для той же цели подошел бы имеющийся механизм сообщений:
procedure LoadLng(var lngmsg: TLangMessage); message CHANGE_LANGUAGE;

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

Пока готов согласиться с alexs в том, что потребность в наследовании формы - последствие ошибки проектирования
Из своего опыта - чем слабее связи между формами - тем проще отладка и поиск ошибок. Или другими словами - чем меньше одна форма знает от другой, тем лучше...

[debi12345]

Вот в Double Commander используется наследование форм - определена абстрактная форма TfrmLng (которая определяет единственную абстрактную процедуру LoadLng и событие OnCreate с вызовом LoadLng), а от нее наследуют все остальные формы и переопределяют LoadLng - IMHO гемор (из-за которого у меня время от времени вылетает lazarus...) - для той же цели подошел бы имеющийся механизм сообщений:
procedure LoadLng(var lngmsg: TLangMessage); message CHANGE_LANGUAGE;

Вот это и есть проблемы проектирования (и понимания процесса обработки событий ) - что и как вынести в генерик-код. А вылетание лазаруса - проблема лазаруса ( пинайте его команду ).

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

Генерик-форма содержит акции, привязаные к ним кнопки, а также datasource. Акции работают с БД через {datasource.dataset.*}. Там же прописана обработка datasource-событий.
В клиентские формы добавляется datagrid, привязанный к {generic.datasource}. Увязка клиентских dataset c {generiс.datasource.dataset} делается в OnCreate этих форм.
Как результат, клиентсткие формы не содержат НИКАКОГО кода, кроме присвоения в OnCreate. Новая таблица со всем сервисом отображения/редактирования/записи делается за пару минут. Это "плохой дизайн" проекта ???

Делегирование, кстати, в коде делать придется - то есть прощай, смысл использования лазаруса как RAD. Но я смотрю, народ перестал уже ждать исправления глюков лазаруса вокруг datamodule & наследования форм - вот и приспособился в коде создавать ( и настраивать ) компоненты. Теперь лечите остальных "Ой, как хорошо все в коде делать - полная управляемость,... ". Не RAD это - и точка !

[Attid]

свои пять копеек брошу.

на самом деле наследование это хорошо, если уметь им позьваться то сокращает время в разработке.

Не RAD это - и точка !

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

[alexs]

во как народ разогрелся - а то с начала недели тут тишина стояла

кстати, особо страждущим, визуальное наследование в лазаре всётаки есть, он там не очень доделано, всё равно ндо руками чуть писать, но если покапать в истории по форуму - тут это пробегало
что б ещё такого сказать - чтобы всем было не скучно

[shade]

Не, без флейма никуда

Генерик-форма содержит акции, привязаные к ним кнопки, а также datasource. Акции работают с БД через {datasource.dataset.*}.
...

В Delphi это решалось без наследования с помощью DataModule... Только вот в лазаре, как вы пометили, дожидаться поддержки датамодуля, видимо, прийдется долго. Тем не менее поддержка датамодуля в лазаре никак не повлияет на мое мнение (читай ниже).

Делегирование, кстати, в коде делать придется - то есть прощай, смысл использования лазаруса как RAD

Ну если руки отвыкли от клавиатуры и привыкли к мыши, то конечно же будет SAD вместо RAD. А так можно даже и без среды очень неплохо RADить - за пару лет программирования на PHP успел разлюбить технику DataSet/DataSource и последние два проекта RADил без всяких DataSet/DataSource... На самом деле, при наличии опыта и хорошего (а не со справочником) знания SQL и соответствующего API, кодинг занимает ничуть не больше времени, чем настройка мышкой многочисленных свойств и связей бд-компонентов. Просто альтернативная стратегия работы с БД - совершенно не популярная среди (идоло?)поклонников Dephi-подобных сред.

к сведению: я редко программирую под БД в Delphi (и пока не приходилось в Lazarus)

[debi12345]

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

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

[Sergei I. Gorelkin]

Я вообще в первые слышу про визуальное наследование... и никогда не испытывал трудностей с его отсутствием. Может кто-нибудь объяснит что-к-чему, с чем едят, когда и где появилось (в Delphi 6 не нашел - не там искал?)?

Есть оно там, и появилось гораздо раньше (в Дельфи 4 точно было). Это наследование на уровне .dfm файлов. Грубо говоря, бросаем на форму кнопки "ОК" и "Отмена", потом от нее наследуем еще 100 разных форм - и на каждой эти кнопки сразу есть, и удалить их нельзя, но можно менять свойства. Если свойство было изменено, оно берется из наследника, если нет - из предка. Любое изменение предка тут же отражается на всех наследниках (или не отражается - см. предыдущее предложение ). Короче говоря, все это подходит только для тех проектов, которые в принципе не планируется поддерживать...

[Tiger]

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

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

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