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

Вопросы программирования и использования среды Lazarus.

Модератор: Модераторы

Сообщение alexs » 06.07.2007 20:27:41

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

это ошибка проектирования приложения если у тебя куча одинаковых форм с одними и темиже элемиентами ввода данных. Обычно народ даже на слышал о таком понятии как нормализация данных - отсюда и вытекает куча одинаковых форм для ввода чёрти-чего, а затем возникают вопросы о бесполезности FK в данных
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4060
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение Attid » 06.07.2007 22:20:18

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


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

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


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

ну и в конце если если останавливает только это то можно обойтись костыликами ну или добавить код в лазарь, в МСЕ ведь есть перенести можно при желании.
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение debi12345 » 06.07.2007 22:44:37

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

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

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

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

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

Ну, народ - не вы барса-лазаруса дрессируете, а он вас. Привыкли к тому, с чем наоборот нужно вести непримиримый джихад :)
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5759
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

Сообщение Tiger » 09.07.2007 01:41:29

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


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

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


И какой смысл рисовать под разные АРМы одного программного комплекса разные во всём окна? Нет, конечно совсем все окна одинаковые быть не могут - это и ежу понятно, но, вот мой пример выше: управляющие элементы будут одни и те же: Таблица, и ряд кнопок под, над, сбоку от нее - кому как нравится! со своими общими от предка текстами-надписями, или специфическими. В потомках же уже можно дорисовывать очень специфичные для формы элементы - этого, вроде, никто не запрещает? - это как раз и дает массу удобств - использовать порождение/наследование не только в коде, но и в дизайне - то, чего так не хватает в Лазаре.
Последний раз редактировалось Tiger 11.07.2007 01:44:59, всего редактировалось 1 раз.
Tiger
новенький
 
Сообщения: 10
Зарегистрирован: 23.05.2006 19:38:26
Откуда: Москва

Сообщение Портос » 09.07.2007 07:34:14

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


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

Кстати, господа! Спешу пофлеймить, пока модер не забанил. Нашел я пути неведомые, кроссплатформенные. Но эффективныя!.. :shock:
Короче, так. Не заморачиваясь, пишем на Дельфи (я - на D7). А полученное приложение крутим хошь под виндой, хошь под Linux/wine. Дешево и сердито! :)
Портос
незнакомец
 
Сообщения: 3
Зарегистрирован: 05.07.2007 07:17:21

Сообщение debi12345 » 09.07.2007 08:11:28

под Linux/wine.

Все равно не то. Для адаптации написанных Вынь32-приложений нормалек - сам TitalCommander таким образом использую.
Но для новых Линукс-приложений - не вижу смысла. В первую очередь - проблемы для работы на низкоуровнем аппаратном уровне. Вторая - печать. Третья - различные системы секьюрити типа "security tokens".
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5759
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

Сообщение tria » 09.07.2007 11:02:22

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

В коде просто указываем:
TfmEdDoc = class(TfmEditPerechn)
и, на сколько я помню, надо бы закрыть-открыть фрму, а мож и Лазаря...
давно это было, уже не помню точно все что.
tria
постоялец
 
Сообщения: 401
Зарегистрирован: 03.04.2006 11:24:10

Сообщение alexs » 09.07.2007 16:06:12

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

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

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

всё хорошо - я тоже так работаю - но всёж родные линуксовые притложения работают стабильней и быстрее - в вине есть глюки
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4060
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение debi12345 » 09.07.2007 18:29:19

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

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

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

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

О чем спорим, народ ??? Нашли что оспаривать - удобство визуального наследования форм ! Пинайте команду лазаруса - чтобы оно появилось.
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5759
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

Сообщение alexs » 10.07.2007 09:11:54

debi12345 писал(а):О чем спорим, народ

в споре рождается истина :lol: :lol:
debi12345 писал(а):Пинайте команду лазаруса

а вот это одобрям
хотя можно (и нужно) и самим что нибудь привносить
Аватара пользователя
alexs
долгожитель
 
Сообщения: 4060
Зарегистрирован: 15.05.2005 23:17:07
Откуда: г.Ставрополь

Сообщение Tiger » 11.07.2007 01:33:37

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

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

alexs писал(а):и где тут место визуальному наследованию?

Перечитай и осмысли еще раз мой пост ранее, целиком! и конец поста особенно, где полужирным выделено! Я там, по-моему, даже повторяюсь :-)
Tiger
новенький
 
Сообщения: 10
Зарегистрирован: 23.05.2006 19:38:26
Откуда: Москва

Пред.

Вернуться в Lazarus

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 34

Рейтинг@Mail.ru