Какой смысл оформлять классы, не имеющие...

← →
Cyrax © (2006-12-05 23:22) [0]

...графического представления на экране, в виде компонентов ?
1. Какой смысл генерировать для них надуманные события, если событий (в нормальном понимании) у них быть не должно...

2. Почему возникают такие вопросы, в Delphi и Builder"е вся организация классов представлена в виде компонентов. Можно, конечно, и без перетаскивания красивых квадратиков обойтись, но в этих IDE всё направлено именно на последнее.
Если проект разрабатывает несколько человек, каждый пишет какой-то модуль, библиотеку, то там естественно, эти самые чудесные
квадратики никому не нужны...
Выходит, что эти IDE не ориентированы на командную разработку...

← →
default © (2006-12-05 23:23) [1]

так и до дурдома не далеко
остановись, Cyrax

← →
Loginov Dmitry © (2006-12-05 23:24) [2]

Что за бред?

← →
Marser © (2006-12-05 23:28) [3]

Смайлик :fool:

← →
Чапаев © (2006-12-05 23:29) [4]

Удалено модератором
Примечание: Жаргон меняем

← →
Cyrax © (2006-12-05 23:33) [5]

Отчего такая негативная реакция ?
Неужели за живое....

Чапаев © (05.12.06 23:29) [4]
Сразу видать, что аффтар с детского сада в командной разработке упражняется!

Прямо с кубиков в команду...

default © (05.12.06 23:23) [1]
так и до дурдома не далеко
остановись, Cyrax

Ну ты что, я только начал... Вопросы то актуальные...

← →
Чапаев © (2006-12-05 23:36) [6]

> Отчего такая негативная реакция ?
Потому что Пазитрон_Брэйн чемпион и нефиг стараться занять его заслуженное первое место в орешнике.

← →
iZEN © (2006-12-05 23:39) [7]

> Cyrax © (05.12.06 23:22)

Типа UML. Ж))

← →
Celades © (2006-12-05 23:41) [8]

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

И как это связано?
Код + форма вот и весь "модуль", в чем проблема для командной разработки не понятно. Конечно, когда не нужна форма, то и компоненты некуда перетаскивать, а значит нет и "проблемы". А когда форма есть и так, то почему бы и нет? За то как легко редактировать свойства и т.д. Удобно.
Вобщем проблема надуманна.

← →
Cyrax © (2006-12-05 23:44) [9]

>Marser © (05.12.06 23:28) [3]
>Смайлик :fool:
то бишь придурок ?

← →
Marser © (2006-12-05 23:51) [10]

> Cyrax © (05.12.06 23:33) [5]
> Отчего такая негативная реакция ?

Негативная? У меня просто недоумение, хотя я и понимаю, что это банальная провокация :-)

← →
Nic © (2006-12-05 23:59) [11]

1. Мне класс удобнее тем, что представляет собой замкнутую систему. То бишь код, данные -- всё как бы в одной обёртке.

2. Ты никогда не писал проект без формы? При разработки 3d движка формы нах не нужны ;)

← →
MsGuns © (2006-12-06 00:01) [12]

да он прикалывается, а вы в кулачки ;)

← →
Marser © (2006-12-06 00:11) [13]

> Cyrax © (05.12.06 23:44) [9]
> >Marser © (05.12.06 23:28) [3]
> >Смайлик :fool:
> то бишь придурок ?

http://forum.pravda.com.ua/smileys/fool.gif

← →
Vga © (2006-12-06 08:33) [14]

> [0] Cyrax © (05.12.06 23:22)

Потому что так удобнее. А нормальное понимание событий - это как? Норма - это вообще весьма расплывчатое понятие, это чуть ли не на половине гуманитарных дисциплин говорят (я в техническом ВУЗе учусь, однико и там есть гуманитарные дисциплины).
TTimer.OnTimer - надуманное событие?
К тому же, не обязательно их на форму кидать, запросто можно создавать как обычный объект.
А еще есть такая штука, как Data Module, модуль без формы, для тех, кому нравится эти квадратики на форму кидать. У такого модуля есть псевдоформа для кидания невизуальных компонентов.

← →
Kolan © (2006-12-06 08:39) [15]

> в виде компонентов

Сериализация?

> в нормальном понимании

Что такое события в нормальном понимании?

Прочти про TComponent у Пачеко, plz...

← →
Сергей М. © (2006-12-06 08:50) [16]

> в Delphi и Builder"е вся организация классов представлена
> в виде компонентов

Сам додумался ?
Или в каких-нть Архангельских начитался этой галиматьи ?)

← →
Anatoly Podgoretsky © (2006-12-06 09:40) [17]

> Marser (06.12.2006 00:11:13) [13]

Не доверяю я сайтам с именем Правда, по части правды, как правило лохотрон.

← →
Marser © (2006-12-06 10:01) [18]

> Anatoly Podgoretsky © (06.12.06 09:40) [17]
> > Marser (06.12.2006 00:11:13) [13]
>
> Не доверяю я сайтам с именем Правда, по части правды, как
> правило лохотрон.

Да относитесь как угодно, то ведь просто смайлик с форума :-)
В крайнем случае http://www.diletant.com.ua/forum/smiles/fool.gif
(в первоисточнике не нашёл)

← →
Vga © (2006-12-06 10:18) [19]

> [18] Marser © (06.12.06 10:01)

Еще вроде в ICQ5 такой есть :) По крайней мере в теме ICQ5 в квипе - точно :) Только не помню его текстового представления... Вот, нашел, :-/ :-\

← →
Cyrax © (2006-12-06 23:57) [20]

>Marser © (05.12.06 23:51) [10]

Это не провокация - это реальный вопрос в провокационной форме (люблю провоцировать беспорядки..)

>Celades © (05.12.06 23:41) [8]
>И как это связано?
>Код + форма вот и весь "модуль", в чем проблема для командной
>разработки не понятно. Конечно, когда не нужна форма, то и компоненты
>некуда перетаскивать, а значит нет и "проблемы". А когда форма есть и
>так, то почему бы и нет? За то как легко редактировать свойства и т.д.
>Удобно.
>Вобщем проблема надуманна.

1. Большинство членов команды дизайном форм не занимаются, куда важнее функциональная часть проекта. Как быть таким членам команды ? Им не нужны никакие формы с чудесными квадратиками !!! Delphi и C++Builder всеми силами навязывают нам визуальное использование этих компонентов, а не функциональное (здесь я как раз о невизуальных компонентах), поскольку эти IDE (повторюсь) в большей степени ориентированы на размещение компонентов на форме или в DataModule"ах. Кроме того, грани между визуальными и невизуальными компонентами минимальны - что это за идиотизм ? (опять провокация..)
2. Ещё один момент. По поводу "легко редактировать свойства". Допустим, отредактируем эти свойства - и что дальше ? Где у нас в коде будут устанавливаться эти свойства ? А нигде - в dfm-ках !!! Так о какой модульности идёт речь ???
Выходит, что проблема то ничуть не надуманна...
3. Сама организация компонентов. При невизуальном использовании компонентов приходится выполнять действия, которые автоматически выполнялись бы при их визуальном использовании, в частности, присваивание свойствам-событиям компонента своих процедур и функций, оформленных необходимым образом. Да и не только это. Многие такие действия неэффективны и надуманны. Почему ? - да потому что компоненты визуальные, и вся их настройка ориентирована на визуальное использование...

>Nic © (05.12.06 23:59) [11]
>1. Мне класс удобнее тем, что представляет собой замкнутую систему. То

>бишь код, данные -- всё как бы в одной обёртке.
Угу: инициализация свойств (собственно, данные) - в dfm-ках, "обработчики" - в pas-ах. Вот и единая обёртка...

>2. Ты никогда не писал проект без формы? При разработки 3d движка >
>формы нах не нужны ;)

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

>Vga © (06.12.06 08:33) [14]
Скажем, события компонента TXMLDocument. Идиотизм !!!

← →
Marser © (2006-12-07 00:03) [21]

> Cyrax © (06.12.06 23:57) [20]
> >Marser © (05.12.06 23:51) [10]
>
> Это не провокация - это реальный вопрос в провокационной
> форме (люблю провоцировать беспорядки..)

Заметно. Я на форумах не первый день, а за последний год поимел форумного опыта раза в два больше по сравнению с предыдущими - такое уже спинным мозгом чувствую :-)

← →
Чапаев © (2006-12-07 00:20) [22]

> Как быть таким членам команды ?
Убить себя апстену.

> Им не нужны никакие формы с чудесными квадратиками !!!
А больше восклицательных знаков можешь?

> и C++Builder всеми силами навязывают нам визуальное использование
> этих компонентов, а не функциональное
Это масонский заговор.

> Многие такие действия неэффективны и надуманны. Почему ?
> - да потому что компоненты визуальные, и вся их настройка
> ориентирована на визуальное использование...
Ужасно. Как это я с ADO общался из консольки, ума не приложу.

> счастью, в основном занимаюсь функциональностью проектов.
Угу. С неполным высшим.

> Гораздо эффективнее и качественнее можно было бы их организовать
> в некомпонентном варианте...
Организуй. Не брызжи так слюной и не используй знаки препинания столь неэкономно. Ты ещё молод, тебе жить да жить, до старости можешь все запасы растратить.

← →
Virgo_Style © (2006-12-07 00:30) [23]

Cyrax © (06.12.06 23:57) [20]
При невизуальном использовании компонентов приходится выполнять действия, которые автоматически выполнялись бы при их визуальном использовании, в частности, присваивание свойствам-событиям компонента своих процедур и функций, оформленных необходимым образом. Да и не только это. Многие такие действия неэффективны и надуманны. Почему ? - да потому что компоненты визуальные, и вся их настройка ориентирована на визуальное использование...

У меня все извилины заплелись об этот абзац... "Невизуально" использовать компоненты неудобно, так как неудобно делать то, что удобнее сделать визуально, поэтому визуальные компоненты - зло.
Я правильно понял?

← →
Чапаев © (2006-12-07 00:38) [24]

> У меня все извилины заплелись об этот абзац...
Так и было задумано.

← →
vuk © (2006-12-07 01:22) [25]

to Cyrax © (06.12.06 23:57) [20]:
>Им не нужны никакие формы с чудесными квадратиками !!!
TSomeComponent.Create(...) и - вперед. Кто мешает-то?

>Delphi и C++Builder всеми силами навязывают нам визуальное
>использование этих компонентов
Угу, пришли и за спиной с топором стоят.

>Кроме того, грани между визуальными и невизуальными компонентами
>минимальны
Нифига себе... Это как?

>Где у нас в коде будут устанавливаться эти свойства ?
>А нигде - в dfm-ках !!!
Так нигде или в dfm-ках? Определитесь для начала. ;o)

>Так о какой модульности идёт речь ???
О вполне себе нормальной модульности. Что, если формы использовать, то модульность уже не работает? Или Вы о чем?

>в частности, присваивание свойствам-событиям компонента своих
>процедур и функций, оформленных необходимым образом
Про callback-и слышали? Полный аналог. Не понятно, почему это плохо.

>Многие такие действия неэффективны и надуманны
Вы уверены, что это Вам не кажется?

>Гораздо эффективнее и качественнее можно было бы их организовать в
>некомпонентном варианте...
И в чем была бы разница? Инициализация не нужна? Да нет, вроде тоже нужна. Тогда что?

← →
Юрий Зотов © (2006-12-07 02:23) [26]

В сотый раз одно и тоже - очередной знаток со знанием дела рассуждает о том, чего не знает и не понимает.

← →
Vga © (2006-12-07 02:42) [27]

> [20] Cyrax © (06.12.06 23:57)

> Это не провокация - это реальный вопрос в провокационной
> форме (люблю провоцировать беспорядки..)

Тролль

> >бишь код, данные -- всё как бы в одной обёртке.
> Угу: инициализация свойств (собственно, данные) - в dfm-
> ках, "обработчики" - в pas-ах. Вот и единая обёртка...

ООП с разделением по файлам путаешь. Тем более, pas+dfm - одно целое.

> >Vga © (06.12.06 08:33) [14]
> Скажем, события компонента TXMLDocument. Идиотизм !!!

Нормальные события.

1-3 - такой бред, что даже нечего ответить, кроме как "извилины заплелись при попытке осмыслить"...

← →
Vga © (2006-12-07 02:43) [28]

> [26] Юрий Зотов © (07.12.06 02:23)

И уже раз в десятый этот знаток - Cyrax...

← →
Piter © (2006-12-07 02:51) [29]

Cyrax © (05.12.06 23:22)
...графического представления на экране, в виде компонентов ?

с тем, чтобы их из панели компонентов можно было кинуть на форму, а не вручную подключать юнит.

Cyrax © (05.12.06 23:22)
1. Какой смысл генерировать для них надуманные события, если событий (в нормальном понимании) у них быть не должно...

классный вопрос. Если событий быть не должно - то их и нету. Смотрим класс, например, XPManifest.

Cyrax © (05.12.06 23:22)
в Delphi и Builder"е вся организация классов представлена в виде компонентов

бред. Даже комментировать не хочется.

Дальше тоже бред...

← →
Eraser © (2006-12-07 03:42) [30]

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

← →
Джо © (2006-12-07 03:53) [31]

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

А, точно. Было такое. Я уж и забыл ник.

← →
Cyrax © (2006-12-07 08:58) [32]

>Eraser © (07.12.06 03:42) [30]
>Джо © (07.12.06 03:53) [31]

Бред, идиотизм...
А вообще, интересно наблюдать, как ругаются детишки...

← →
Сергей М. © (2006-12-07 09:06) [33]

> Cyrax © (07.12.06 08:58) [32]

Ну так все-таки какую же траву ты курил, когда делал вот это официальное заявление

> в Delphi и Builder"е вся организация классов представлена в виде компонентов

?)

← →
Marser © (2006-12-07 09:17) [34]

> Cyrax © (07.12.06 08:58) [32]

А вот за это можно и по ушам от модера схлопотать...

← →
Чапаев © (2006-12-07 09:47) [35]

http://smoking-room.ru/data/misc/stories/flamewarriors.html

← →
StriderMan © (2006-12-07 09:51) [36]

← →
Vga © (2006-12-07 13:01) [37]

> [32] Cyrax © (07.12.06 08:58)

Спасибо, посмешил :р

← →
Cyrax © (2006-12-07 22:37) [38]

>Чапаев © (07.12.06 00:20) [22]
>> счастью, в основном занимаюсь функциональностью проектов.
>Угу. С неполным высшим.

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

> Гораздо эффективнее и качественнее можно было бы их организовать
> в некомпонентном варианте....
>Организуй.

Организовал бы, было бы время....

>Не брызжи так слюной и не используй знаки препинания столь
>неэкономно. Ты ещё молод, тебе жить да жить, до старости можешь все
>запасы растратить.

На тебя что - попало ? Или выклянчить надеешься ?

>Virgo_Style © (07.12.06 00:30) [23]
>У меня все извилины заплелись об этот абзац... "Невизуально"
>использовать компоненты неудобно, так как неудобно делать то, что
>удобнее сделать визуально, поэтому визуальные компоненты - зло.
>Я правильно понял?
Неправильно. Визуальная ориентация компонентов организована в ущерб их невизуальному использованию. Именно в ущерб, поскольку визуальная ориентация сделала эти компоненты/классы крайне неудобными при невизуальном использовании....
И не надо пытаться доказать, что Borland убила двух зайцев одним компонентом - и визуально использовать удобно, и невизуально. Это ЧУШЬ !!!!

>vuk © (07.12.06 01:22) [25]
>>Кроме того, грани между визуальными и невизуальными компонентами
>>минимальны
>Нифига себе... Это как?

Прежде всего организационно (организация классов)....

>>Где у нас в коде будут устанавливаться эти свойства ?
>>А нигде - в dfm-ках !!!
>Так нигде или в dfm-ках? Определитесь для начала. ;o)

Нигде в коде этой инициализации нет. А между всякими UML"ями и кодом должна существовать строгая грань. В Delphi и C++Builder всё перемешано....
(один из хороших примеров - Qt с QtDesigner"ом)

>Так о какой модульности идёт речь ???
>О вполне себе нормальной модульности. Что, если формы использовать, то >модульность уже не работает? Или Вы о чем?

О том, что тремя этажами выше....

>>Многие такие действия неэффективны и надуманны
>Вы уверены, что это Вам не кажется?

Может, и кажется. Я ведь "без башни"....

>>Гораздо эффективнее и качественнее можно было бы их организовать в
>>некомпонентном варианте...
>И в чем была бы разница? Инициализация не нужна? Да нет, вроде тоже
>нужна. Тогда что?

Тогда невизуальные классы были бы максимально приспособлены и максимально эффективны для невизуального использования (именно так они и будут использоваться хорошими программистами), а визуальные - именно для визуального применения. и не было бы никакой каши....

>Юрий Зотов © (07.12.06 02:23) [26]
>В сотый раз одно и тоже - очередной знаток со знанием дела рассуждает о >том, чего не знает и не понимает.

При этом ни один незнаток не может этому знатоку достойно возразить....

>Vga © (07.12.06 02:42) [27]
>Тролль

Кто такой тролль ?

>> >бишь код, данные -- всё как бы в одной обёртке.
>> Угу: инициализация свойств (собственно, данные) - в dfm-
>> ках, "обработчики" - в pas-ах. Вот и единая обёртка...
>ООП с разделением по файлам путаешь. Тем более, pas+dfm - одно целое.

Разделение по файлам - это разделение кода по файлам. dfm - это не исходный код !!!! dfm-ки должны служить для получения кода, инициализирующего визуальные элементы (и где же этот код ?), а не быть частью этого кода.

>> >Vga © (06.12.06 08:33) [14]
>> Скажем, события компонента TXMLDocument. Идиотизм !!!
>Нормальные события.

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

>1-3 - такой бред, что даже нечего ответить, кроме как "извилины
>заплелись при попытке осмыслить"...

Ну уж если и понять никак, то об обоснованных доводах и речи быть не может...

>Vga © (07.12.06 02:43) [28]
>> [26] Юрий Зотов © (07.12.06 02:23)
>И уже раз в десятый этот знаток - Cyrax...

Посади меня в лужу - больше выступать не буду...

>Piter © (07.12.06 02:51) [29]
>>Cyrax © (05.12.06 23:22)
>>...графического представления на экране, в виде компонентов ?
>с тем, чтобы их из панели компонентов можно было кинуть на форму, а не
>вручную подключать юнит.

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

>>Cyrax © (05.12.06 23:22)
>>в Delphi и Builder"е вся организация классов представлена в виде
>>компонентов
>бред. Даже комментировать не хочется.

Согласен, бред. Я имел ввиду конечные классы с конечной функциональностью, то бишь те, которые на вкладках висят....

>Marser © (07.12.06 09:17) [34]
>А вот за это можно и по ушам от модера схлопотать...

Именно поэтому и сдерживаюсь.

>StriderMan © (07.12.06 09:51) [36]
>советую автору все-таки сначала образование получить.

Всему своё время. Сейчас я официально получаю 2 высших....

_________________________________________________________________
Мои основные претензии:
1. dfm-ки не отражаются в код
2. визуальное оформление невизуальных компонентов =>
1. снижение эффективности и удобства их невизуального использования (частая потребность в командной разработке)
2. подсознательная тяга к рисованию цветочков и листочков

И не надо показывать свой консерватизм - ничто не вечно....

← →
Virgo_Style © (2006-12-07 22:45) [39]

Cyrax © (07.12.06 22:37) [38]
Мои основные претензии:
1. dfm-ки не отражаются в код
2. визуальное оформление невизуальных компонентов =>
1. снижение эффективности и удобства их невизуального использования (частая потребность в командной разработке)
2. подсознательная тяга к рисованию цветочков и листочков

1. Затрудняюсь представить ситуацию, когда это необходимо.
Проектируешь визуально - ну и проектируй, невизуально - откуда тогда dfm возьмется?
2. Обоснуй оба подпункта

← →
Чапаев © (2006-12-07 22:57) [40]

> Организовал бы, было бы время....
Ага... На форум его хватает.

> Это ЧУШЬ !!!!
Опять кнопка запала. :о)

> они и будут использоваться хорошими программистами
К коим ты, несомненно, относишь себя?

> Ну уж если и понять никак, то об обоснованных доводах и
> речи быть не может...
О том и речь.

> Посади меня в лужу - больше выступать не буду...
Трудно посадить... Ой как трудно... Сперва вынуть надо.

> dfm-ки не отражаются в код
Софтину, переводящую *.dfm в соответствующий код, можно за полдня написать. Только никому это нафиг не надо.

> подсознательная тяга к рисованию цветочков и листочков
Я, помнится, в десятом классе тоже ужасно ругал Делфи, Винду и прочие "навороты". Суровые сибирские мужики программят исключительно в консоли. Пофиг на время, главное показать, кто тут самый суровый.

← →
Джо © (2006-12-07 23:05) [41]

> Согласен, бред. Я имел ввиду конечные классы с конечной
> функциональностью, то бишь те, которые на вкладках висят....

Стало быть, TStringList какой-нибудь никакой "конечной функциональностью" не обладает. Ну-ну...

← →
@BraIN © (2006-12-07 23:19) [42]

> При этом ни один незнаток не может этому знатоку достойно
> возразить....

— Вон поскакал «неуловимы Джо»...
— А почему неуловимый?
— А кому он собственно нужен?

← →
Юрий Зотов © (2006-12-08 01:01) [43]

> Cyrax © (07.12.06 22:37) [38]

> При этом ни один незнаток не может этому знатоку достойно возразить....

Это невозможно.

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

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

И, значит, будет считать, что "достойно возразить" ему так и не смогли.

===============

PS
Вы, конечно, знаете, чем отличается ламер от чайника, да?
:о)

← →
Юрий Зотов © (2006-12-08 01:07) [44]

> конечные классы с конечной функциональностью, то бишь
> те, которые на вкладках висят....

LOL !!!!!!!!!!!

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

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

Воинствующая табуретка? Этакий табуламер?

← →
Джо © (2006-12-08 01:10) [45]

Никакой новой разновидности, ИМХО. Просто ламер-провокатор, как собственно он и сам признавался.

← →
Другой © (2006-12-08 01:14) [46]

Этакий табуламер?

Звучит ниче так.

← →
vuk © (2006-12-08 01:16) [47]

to Cyrax © (07.12.06 22:37) [38]:
>визуальная ориентация сделала эти компоненты/классы крайне неудобными
>при невизуальном использовании....
Вот Вы все твердите, что неудобно. Это мантра такая что ли? :) Или все-таки расскажете, почему не удобно?

>Прежде всего организационно (организация классов)....
Разница между визуальными и невизуальными компонентами очень большая. Исходники читайте. До полного просветления.

>Нигде в коде этой инициализации нет.
В коде она есть. В коде предка-контейнера. А если говорить о явно прописываемой в коде инициализации, то по-хорошему, такая "инициализация" должна работать в обе стороны, то есть то, что написано руками должно влиять на внешний вид в конструкторе (т.н. Two Way). Насколько я понимаю, в native-среде такое сделать, скажем так, затруднительно. Вот Java/.net - пожалуйста. И в Delphi for .net все это тоже есть. И, кстати, никакого отношения все это не имеет к тому, как библиотека внутри устроена.

>А между всякими UML"ями и кодом должна существовать строгая грань
UML здесь откуда всплыл?

>и не было бы никакой каши....
Ну это может у Вас каша получается. Но это не у всех так.

>Может, и кажется. Я ведь "без башни"....
Ну это Вам изнутри виднее. :)

>dfm - это не исходный код !!!!
Совершенно верно. Не код. С концепцией ресурсов знакомы?

>>> Скажем, события компонента TXMLDocument. Идиотизм !!!
>>Нормальные события.
>Нормальные события этого класса должны генерироваться и отлавливаться
>внутри объектов этого класса (рассматриваем, к примеру, SAX-интерфейс).
Вы о чем вообще? Какой в пень SAX? В TXMLDocument DOM модель используется.

← →
Другой © (2006-12-08 01:23) [48]

Автору б поработать Кларион, когда он(язык) стал ABC. От визуала его бы затошнило, субя по этой ветке. (Хотя и без ABC, в ДОСе, он был орентирован на оконность (визуальность), так сказать).

← →
Vga © (2006-12-08 01:46) [49]

> >Vga © (07.12.06 02:42) [27]
> >Тролль
>
> Кто такой тролль ?

В ru.wikipedia.org, статья "Троллинг".

> И не надо пытаться доказать, что Borland убила двух зайцев
> одним компонентом - и визуально использовать удобно, и невизуально.
> Это ЧУШЬ !!!!

Доказывать не буду. Ты считаешь, что неудобно, я считаю, что вполне нормально. Оба мнения имеют одинаковое право на существование.

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

DFM - это интерпретируемый код.

> >> >Vga © (06.12.06 08:33) [14]
> >> Скажем, события компонента TXMLDocument. Идиотизм !!!
>
> >Нормальные события.
>
> Нормальные события этого класса должны генерироваться и
> отлавливаться внутри объектов этого класса (рассматриваем,
> к примеру, SAX-интерфейс). Наружу ничего вываливаться не
> должно...

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

> >1-3 - такой бред, что даже нечего ответить, кроме как "извилины
> >заплелись при попытке осмыслить"...
>
> Ну уж если и понять никак, то об обоснованных доводах и
> речи быть не может...

Это претензия к тебе - напиши понятнее.

> Посади меня в лужу - больше выступать не буду...

Ты ухитряешься не замечать, как тебя в лужу садят...

← →
Германн © (2006-12-08 01:58) [50]

> Воинствующая табуретка? Этакий табуламер?

Ну вот. ЮЗ расширяет свою (нашу) классификацию ламеров :-)
Запомним, чтобы ввести Кэтмара в курс дела, когда он вернётся. :-)

← →
Gydvin © (2006-12-08 06:48) [51]

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

Не совсем понятно, какой код желает получить автор, но попробуем прислушаться к телепатору. В дизайне, правой клавишей по форме, выбираем "view as text" и то, что там увидим - это и будет код *.dfm. Более того, если уже готовый ехе, открыть редактором ресурсов - увидим то же самое.

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

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

← →
Думкин © (2006-12-08 06:58) [52]

> Gydvin © (08.12.06 06:48) [51]

У него речь немного о другом. Хотя суть претензий так и неясна. Ну не нравится человеку. А что не нравится - четко сформулировать и без ошибок не в состоянии. Несмотря на несколько высших образований.

← →
Чапаев © (2006-12-08 09:35) [53]

> >dfm - это не исходный код !!!!
> Совершенно верно. Не код. С концепцией ресурсов знакомы?

> DFM - это интерпретируемый код.
Хихи... Щас заявит, что "вы сами между собой разобраться не можете, что такое дфм".

← →
Правильный Вася (2006-12-08 11:21) [54]

Cyrax © (07.12.06 22:37) [38]
> Организовал бы, было бы время....
желающий делать - делает, нежелающий дурень - ищет отмазки

← →
Anatoly Podgoretsky © (2006-12-08 12:20) [55]

> Юрий Зотов (08.12.2006 01:01:43) [43]

> А если он в вопросе разбирается именно на уровне табуретки и не более, то хоть обвозражайся - не поймет.

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

← →
Anatoly Podgoretsky © (2006-12-08 12:20) [56]

> Юрий Зотов (08.12.2006 01:01:43) [43]

> Вы, конечно, знаете, чем отличается ламер от чайника, да?

А без табуретки это не понять.

← →
Anatoly Podgoretsky © (2006-12-08 12:21) [57]

> Юрий Зотов (08.12.2006 01:07:44) [44]

табуламер?

Это слово пишется с пробелом и при том второе слово не обязательно.

← →
Anatoly Podgoretsky © (2006-12-08 12:24) [58]

> Думкин (08.12.2006 06:58:52) [52]

А сколько оно стоит высшее образование, а то я не в курсе текущих расценок и вилок.
С технологией знаком.

← →
Игорь Шевченко © (2006-12-08 12:25) [59]

Cyrax © (07.12.06 22:37) [38]

> Я ведь "без башни"....

> Посади меня в лужу - больше выступать не буду...

Ты давно в луже, зачем сажать ?

← →
Думкин © (2006-12-08 12:26) [60]

> Anatoly Podgoretsky © (08.12.06 12:24) [58]

Автор описал. Речь не о дипломах. Он университеты на табуретке в туалете закончил. :)

← →
Anatoly Podgoretsky © (2006-12-08 12:41) [61]

> Думкин (08.12.2006 12:26:00) [60]

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

← →
Vga © (2006-12-08 13:13) [62]

> [53] Чапаев © (08.12.06 09:35)
> > >dfm - это не исходный код !!!!
> > Совершенно верно. Не код. С концепцией ресурсов знакомы?
>
>
>
> > DFM - это интерпретируемый код.
> Хихи... Щас заявит, что "вы сами между собой разобраться
> не можете, что такое дфм".

Интерпретируемый код, засунутый в ресурсы :) Никаких противоречий :)

← →
Vga © (2006-12-08 13:15) [63]

> [54] Правильный Вася (08.12.06 11:21)

Или более корректно: тот, кто хочет - всегда найдет возможность, тот, кто не хочет - всегда найдет отговорку.

← →
Cyrax © (2006-12-08 13:17) [64]

Дела далеко зашли. Решили оторваться.. Бывает...
Вечерком ситуацию проясним, разложим всё по полочкам...

← →
Думкин © (2006-12-09 07:14) [65]

Вечерок прошел. Ситуация не прояснилась. :( Так и запишем.

← →
Чапаев © (2006-12-09 10:25) [66]

прошу отметить в протоколе, что это был вечерок пятнички.

← →
Anatoly Podgoretsky © (2006-12-09 13:32) [67]

> Чапаев (09.12.2006 10:25:06) [66]

А что завтра скажешь? И так семь раз подряд.

← →
Отставник (2006-12-09 13:53) [68]

Просто свой реферат он уже написал, методом копипаст из данной ветки. Потому и не пришел - нужда отпала.

← →
Cyrax © (2006-12-10 22:52) [69]

Virgo_Style © (07.12.06 22:45) [39]

В силу эффективности использования кода или его графических аналогов всё исходное "сырьё", служащее для получения законченной программы, должно быть представлено и сохранено в единообразном формате. Во всяком случае это должен быть либо код на каком-либо языке программирования, либо файлы других форматов для графического представления модели будущей программы.
Здесь же у нас часть кода хранится в pas/cpp -файлах, часть - в dfm-ках.
Возьмём к примеру, UML. Мы же не храним часть модели - в файлах с исходными кодами на каком-то языке программирования, часть - в UML-файлах. У нас вся модель хранится в файлах UML. При желании мы можем получить код на заданном языке программирования. И код этот не будет требовать UML-диаграмм при компиляции.
Т.е. если имеются какие-то средства, облегчающие и автоматизирующие процесс написания кода, то они должны выдавать нам этот код...

>Чапаев © (07.12.06 22:57) [40]
>Я, помнится, в десятом классе тоже ужасно ругал Делфи, Винду и прочие "
>навороты". Суровые сибирские мужики программят исключительно в
>консоли. Пофиг на время, главное показать, кто тут самый суровый.

Это не из той степи. Я не против средств, облегчающих и автоматизирующих процесс разработки, я всего лишь за разделение уровней/этапов этой разработки. Результат каждого этапа должен быть самодостаточным и не зависеть от результатов других этапов: UML-диаграммы, C++-код, нативный код. Или: файлы GUI-интерфейса (разработанные в дизайнере, отдельном или встроенном в IDE) -> код GUI-интерфейса...

← →
Cyrax © (2006-12-10 22:57) [70]

>Джо © (07.12.06 23:05) [41]
>Стало быть, TStringList какой-нибудь никакой "конечной функциональностью
>" не обладает. Ну-ну...

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

← →
Джо © (2006-12-10 23:00) [71]

> [70] Cyrax © (10.12.06 22:57)
> >Джо © (07.12.06 23:05) [41]
> >Стало быть, TStringList какой-нибудь никакой "конечной
> функциональностью
> >" не обладает. Ну-ну...
>
> Конечной, конечно, обладает, но этот тип всё же ближе к
> типам данных и их расширениям. Т.е. функционально имеют
> вспомогательную направленность...

А TDataSet какой-нибудь не имеет "вспомогательной направленности"? Ну-ну...
П.С. Я к чему. Может, пора заканчивать с глобальными обобщениями и заняться, к примеру, самообразованием по предметам, по поводу которых так хочется спорить? Извини за непрошенный совет.

← →
Юрий Зотов © (2006-12-10 23:05) [72]

> Джо © (10.12.06 23:00) [71]

Серег, здорово, дружище.

Ну его, а? Его голова, его каша, его проблемы. Тем более, что чукча не читатель, это уже давно ясно.

Давай пофлудим лучше?

Я вот щас коньячку принял, немножко. Бархатный, подлец.

← →
Джо © (2006-12-10 23:06) [73]

> [72] Юрий Зотов © (10.12.06 23:05)

А я буженинки собственной сделал и водочку охладил. Чувствую, не устоит душа :)

← →
Юрий Зотов © (2006-12-10 23:07) [74]

Эх, блин, и ты меня уел, негодник.

Хачу!!!!

← →
Virgo_Style © (2006-12-10 23:09) [75]

понедельник же на носу

← →
Джо © (2006-12-10 23:09) [76]

> [74] Юрий Зотов © (10.12.06 23:07)

You"re always wellcome! :)
Коньяку хочется страшно, кстати. Полез в шкафчик — а там пусто. Пришлось довольствоваться тем, что бог послал. Ну, да не беда! :0)

← →
Kolan © (2006-12-10 23:10) [77]

> Мы же не храним часть модели - в файлах с исходными

Как вообще можно предположить что модель может хронится в коде программы? Неужели непонятно CASE средства просто предоставляют средаства прямого проектирования? Что за идиотское сравнение?

← →
Джо © (2006-12-10 23:10) [78]

> [75] Virgo_Style © (10.12.06 23:09)
> понедельник же на носу

Да ну его к лешему. Не напоминай...

← →
Юрий Зотов © (2006-12-10 23:11) [79]

Гы... а зачем злоупотреблять? Мы не из таких.

Ежели под хорошую буженинку, да с чесночком, то 700 грамм на рыло качеству и количеству кода только способствуют.

← →
Kolan © (2006-12-10 23:11) [80]

Э, ребзя вы че? Теперь и я захотел...

← →
vuk © (2006-12-10 23:13) [81]

to Cyrax © (10.12.06 22:52) [69]:
>Возьмём к примеру, UML.
Не, не возьмём. Он здесь ни при чем и к .dfm отношения не имеет. :)

to Юрий Зотов © (10.12.06 23:05) [72]:
>Я вот щас коньячку принял, немножко. Бархатный, подлец.
Издеваешься!? Вот негодяй! :))

← →
Юрий Зотов © (2006-12-10 23:13) [82]

О!!! Дискуссия явно оживилась!!!

← →
Джо © (2006-12-10 23:14) [83]

Да. Возьмем это UML. За это самое... И в окошко. %)

← →
Алхимик © (2006-12-10 23:16) [84]

Прочитал ветку - ничего не понял, но выпил водки.
Прозит, господа!

← →
Юрий Зотов © (2006-12-10 23:17) [85]

А в слове "UML" последняя буква - это ""liquid", надеюсь?

← →
Юрий Зотов © (2006-12-10 23:18) [86]

> Алхимик © (10.12.06 23:16) [84]

Наш человек! Сразу видно - настоящий программер!

← →
Павел Калугин © (2006-12-10 23:20) [87]

> [82] Юрий Зотов © (10.12.06 23:13)

Садист, однозначно.....

← →
Алхимик © (2006-12-10 23:20) [88]

> [86] Юрий Зотов © (10.12.06 23:18)
> > Алхимик © (10.12.06 23:16) [84]
>
> Наш человек! Сразу видно - настоящий программер!

Дядя Юра, а можно я эту цитату в своё резюме впишу?
Мой потенциальный работодатель оценит на все сто процентов!
:)

← →
Джо © (2006-12-10 23:21) [89]

> [85] Юрий Зотов © (10.12.06 23:17)
> А в слове "UML" последняя буква - это ""liquid", надеюсь?

Угу.
Undefined Malicious Liquid :_)

← →
Kolan © (2006-12-10 23:23) [90]

> А в слове "UML" последняя буква - это ""liquid", надеюсь?

Unified Mindclearing Liquid :)

Садисты, а мне пропустить грамм 250 невыйдет сейчас, а хочется... :)

← →
Юрий Зотов © (2006-12-10 23:25) [91]

> Павел Калугин © (10.12.06 23:20) [87]

Причем того самого, Паш. Ну, ты знаешь, какого. Зацени мою сволочность?

> Алхимик © (10.12.06 23:20) [88]

Без проблем. Но 40 процентов гораздо лучше, чем 100.

← →
Юрий Зотов © (2006-12-10 23:26) [92]

> Kolan © (10.12.06 23:23) [90]

> Mindclearing

Браво!

← →
Cyrax © (2006-12-10 23:29) [93]

>@BraIN © (07.12.06 23:19) [42]
>— Вон поскакал «неуловимы Джо»...
>— А почему неуловимый?
>— А кому он собственно нужен?

Скажу честно: зачёт...

>Юрий Зотов © (08.12.06 01:01) [43]
>То есть, возражать-то можно сколько угодно, но для того, чтобы твои
>возражения хотя бы были приняты, как возражения (уж не говоря о том,
>чтобы с ними согласились), нужно, чтобы тот, кому возражают ну хотя бы
>немного разбирался в вопросе. Ну хотя бы чуть лучше табуретки.
>А если он в вопросе разбирается именно на уровне табуретки и не более,
>то хоть обвозражайся - не поймет. Потому что понять просто не может.
>И, значит, будет считать, что "достойно возразить" ему так и не смогли.

lol... так вы мне возражайте...

>Вы, конечно, знаете, чем отличается ламер от чайника, да?

Знаю...

>Юрий Зотов © (08.12.06 01:07) [44]
>Раньше я считал, что ламер - это воинствующий чайник. И жизнь это не
>раз подтверждала.
>Но тут определилась новая разновидность - воинствующий (причем весьма
>активно), но даже до чайника не дотягивает (причем весьма сильно).
>Воинствующая табуретка? Этакий табуламер?

1 вариант: получаю RO, предварительно ответно оторвавшись...
2 вариант: отшучиваюсь и ухожу в сторону...
3 вариант: пытаюсь показать некорректность нападков, нет, лучше наездов...

Ни одного из вариантов тут не реализую. Элементы 1 варианта проимплементированы мысленно, для 2-го слишком трезв, 3-й - слишком "правильный".

>Джо © (08.12.06 01:10) [45]
>Никакой новой разновидности, ИМХО. Просто ламер-провокатор, как
>собственно он и сам признавался.

В чём конкретно я признавался ?
Подтверди конкретным примером... (мог бы дописать: либо... - а дальше придумать что-нибудь для тебя неприятное. Но это слишком предсказуемо и банально)

>Германн © (08.12.06 01:58) [50]
>Ну вот. ЮЗ расширяет свою (нашу) классификацию ламеров :-)
>Запомним, чтобы ввести Кэтмара в курс дела, когда он вернётся.

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

>Другой © (08.12.06 01:14) [46]
>Этакий табуламер?
>Звучит ниче так.

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

>Anatoly Podgoretsky © (08.12.06 12:20) [55]
>> Юрий Зотов (08.12.2006 01:01:43) [43]
>> А если он в вопросе разбирается именно на уровне табуретки и не более, то
>>хоть обвозражайся - не поймет.
>Для лучшего понимания надо использовать табуретку по прямому назначению - по >голове. И так много раз.

Анатолий, вы во мне азарт пробуждаете. Вспомнил уж тут московскую "прописку", которую Gero обещал...

← →
Юрий Зотов © (2006-12-10 23:31) [94]

Вот так. Пришел Жан...

← →
Чапаев © (2006-12-10 23:35) [95]

> подобные высказывания - это всего лишь очередная попытка
> показать и почуствовать себя крутым перцем, ветка же - всего
> лишь повод для этого
Почувствовал?

← →
Джо © (2006-12-10 23:35) [96]

Нет, вы не поверите, до чего же полегчало. Просто заново родился.

← →
Cyrax © (2006-12-10 23:43) [97]

>vuk © (08.12.06 01:16) [47]
>>Нигде в коде этой инициализации нет.
>В коде она есть. В коде предка-контейнера.

Я говорю об инициализации в коде. Таковой не имеется. Это факт.

>А если говорить о явно
>прописываемой в коде инициализации, то по-хорошему, такая "
>инициализация" должна работать в обе стороны, то есть то, что написано
>руками должно влиять на внешний вид в конструкторе (т.н. Two Way).
>Насколько я понимаю, в native-среде такое сделать, скажем так,
>затруднительно. Вот Java/.net - пожалуйста. И в Delphi for .net все это
>тоже есть. И, кстати, никакого отношения все это не имеет к тому, как
>библиотека внутри устроена.

Ну так если изменить параметры в dfm-ке, то в конструкторе с большой вероятностью эти изменения отразятся...
Да и без two way можно запросто обойтись...

>А между всякими UML"ями и кодом должна существовать строгая грань
>UML здесь откуда всплыл?

Более понятный пример привожу...

>dfm - это не исходный код !!!!
>Совершенно верно. Не код. С концепцией ресурсов знакомы?

А вот об этом можно и в отдельной ветке поговорить...)

← →
Cyrax © (2006-12-10 23:50) [98]

>Vga © (08.12.06 13:15) [63]
>> [54] Правильный Вася (08.12.06 11:21)
>Или более корректно: тот, кто хочет - всегда найдет возможность, тот, кто >не хочет - всегда найдет отговорку.

Мне Васькино высказывание больше нравится - как более агрессивное...
Что по делу, то вещь реализуемая, можешь выбрать компонент, который требуется реализовать более эффективно (с невизуальной ориентацией) и быстрее...
(займёт 3 место в очереди проектов (Default - Ketmar - Vga))///

← →
Romkin © (2006-12-10 23:53) [99]

Юрий Зотов © (10.12.06 23:31) [94] Как пришел, так и уйдет... А у меня проблема: есть коньяк, но я его не люблю :( просто для готовки...
Есть ведерко квашеной капусты, но нет водки :(
Какие тут компоненты, млин :(

← →
Virgo_Style © (2006-12-10 23:53) [100]

100-й пост на носу, а я все еще теряюсь в догадках, чем компонент с визуальной ориентацией отличается от компонента с невизуальной ориентацией

← →
Cyrax © (2006-12-10 23:55) [101]

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

Скажем так, рассказывать про себя я ничего не собираюсь, кроме того, что в анкете время от времени появляется...

← →
Cyrax © (2006-12-10 23:58) [102]

>Virgo_Style © (10.12.06 23:53) [100]
>100-й пост на носу, а я все еще теряюсь в догадках, чем компонент с
>визуальной ориентацией отличается от компонента с невизуальной
>ориентацией

Компонент с визуальной ориентацией ориентирован на визуальное применение, с невизуальной - на невизуальное...

← →
Чапаев © (2006-12-11 00:05) [103]

Самурай без меча подобен самураю с мечом. Но без меча.

← →
Cyrax © (2006-12-11 00:06) [104]

Если честно, то та ветка была довольно интересна... Лично я не против (это модераторам)...

← →
vuk © (2006-12-11 00:21) [105]

to Cyrax © (10.12.06 23:43) [97]:
>Таковой не имеется. Это факт.
Не имеется. И что?

>Ну так если изменить параметры в dfm-ке, то в конструкторе с большой
>вероятностью эти изменения отразятся...
Разница есть. И весьма существенная. Для отображения изменений в .dfm не нужно компилировать и выполнять исходный код. Достаточно просто загрузить данные, коими .dfm и является.

>Да и без two way можно запросто обойтись...
Two way, оно либо есть, и тогда изменения в исходнике будут отображаться в дизайнере и наоборот, либо его нет.

>Компонент с визуальной ориентацией ориентирован на визуальное
>применение, с невизуальной - на невизуальное...
Поскольку Вы продолжаете твердить мантры, вместо объяснений, то вопросы буду задавать я.

Возмем банальную кнопку - TButton. Что там ориентировано на "визуальное применение" и чем от TButton будет отличаться кнопка, на это применение не ориентированная?

← →
Юрий Зотов © (2006-12-11 00:47) [106]

> vuk © (11.12.06 00:21) [105]

> чем от TButton будет отличаться кнопка, на это применение
> не ориентированная?

Леш, ты что, офигел, такие сложные вопросы задавать? А еще меня садистом обзываешь.

Из этой ветки следует, что под "визуальными компонентами" товарисч понимает то, что он видит сначала в палитре, а если бросить на форму - то и на форме. Еще визуальные компоненты обладают законченной функциональностью. То есть, TMenu - это у него визуальный компонент.

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

Леш, ты что, офигел, такие сложные вопросы задавать? А еще меня садистом обзываешь.

← →
ors_archangel © (2006-12-11 00:47) [107]

> Какой смысл оформлять классы, не имеющие...
> ...графического представления на экране, в виде компонентов
> ?

В этом согласен с Cyrax, может нужно было объединить визуальное и невизуальное, любой класс - квадратик с publishedными свойствами и наоборот, только не на форме, а отдельно, например, выбираешь класс в Explorerе, а в Инспекторе тебе его свойства можно редактировать, обработчики назначать. Хорошо, если бы была палитра классов, разложены по категориям/юнитам, удобно, берёшь его, перетаскиваешь куда-нить в код, даёшь имя, а юнит сам юзится автоматом, тогда невизуальное можно было бы отделить без потерь в скорости разработки... Обработчики - тоже согласен с Cyrax - совершенно не правильно, что отделены от классов, с которыми они связаны, если я, допустим, нажимаю на кнопку Button1, я бы хотел, чтобы это событие обрабатывалось в TButton1.ClickEvent каком-то что ли, ну не как в TForm1.Button1Click (хорошо хоть что не вообще глобальная функция как в Visual Basic), это не удобно хотя бы тем, что для доступа к полям, собсвенно, Button1, нужно разбираться кто есть Sender, вообще, когда я ввожу какию-нить переменную, связанную только с Button1, я не смогу её вствить в описание TButton1, потому что его просто нет, неужели надо создавать новый компонент для этого? По-моему, должна быть возможность расширять описание любого подкомпонента формы. Мне лично тоже не нравится концепция хранить начальные свойства и привязку событий в ресурсах (dfm), лучше бы генерация как dotnet, и чтобы изменять её можно было в редакторе (много хочу, наверно, а ведь в KOL/MCK что-то подобное уже есть), тогда бы и размер можно была контролировать как-то экзешников, но говорят же: лучшее - враг хорошего?

← →
Юрий Зотов © (2006-12-11 00:55) [108]

Руслан Сергеевич, с днем архангела Вас. Извините, что на день раньше.

А по поводу "когда я ввожу какию-нить переменную, связанную только с Button1, я не смогу её вствить в описание TButton1, потому что его просто нет, неужели надо создавать новый компонент для этого? По-моему, должна быть возможность расширять описание любого подкомпонента формы" разрешите Вас напомнить что есть такой краеугольный камень ООП, как наследование. И его пока не отменяли.

← →
vuk © (2006-12-11 01:01) [109]

to Юрий Зотов © (11.12.06 00:47) [106]:
>Из этой ветки следует
Юр, я не люблю упражнений в телепатии и предпочитаю, чтобы человек сам рассказал, что он под чем понимает. Он пока не колется. Подождем. :)

to ors_archangel © (11.12.06 00:47) [107]:
>берёшь его, перетаскиваешь куда-нить в код, даёшь имя, а юнит сам
>юзится автоматом
Не, ну совсем народ обленился! :)

>я бы хотел, чтобы это событие обрабатывалось в TButton1.ClickEvent
Вы предлагаете на каждый чих рожать наследника от TButton? Или что Вы имеете в виду?

>По-моему, должна быть возможность расширять описание любого
>подкомпонента формы.
Есть два метода расширения функциональности - наследование и делегирование (через события). Какой Вы предпочитаете? И понимаете ли, что последует за использованием каждого из методов?

← →
ors_archangel © (2006-12-11 01:08) [110]

> Юрий Зотов © (11.12.06 00:55) [108]

> Руслан Сергеевич, с днем архангела Вас. Извините, что на
> день раньше.

Спасибо!
Значит можно писать:
TButton1 = class(TButton) somefield: TSomeType; end; TForm1 = class(TForm) Button1: TButton1; end;?
А в остальном согласен?

← →
Юрий Зотов © (2006-12-11 01:08) [111]

> vuk © (11.12.06 01:01) [109]

Какая-такая телепатия? Он уже все сам написал.

А ты, Леш, точно садист: "Есть два метода расширения функциональности - наследование и делегирование (через события). Какой Вы предпочитаете? И понимаете ли, что последует за использованием каждого из методов?".

Не, ну так нельзя. Хлопцы ж теперь спать не будут. Оказывается, все уже до них придумано, а мужики-то и не знали!

← →
Юрий Зотов © (2006-12-11 01:14) [112]

> ors_archangel © (11.12.06 01:08) [110]

> Значит можно писать:
> TButton1 = class(TButton)
> somefield: TSomeType;
> end;
> TForm1 = class(TForm)
> Button1: TButton1;
> end;

Руслан Сергеевич, а ведь можно. Вот чес-слово, можно. И даже проблем с DFM не будет, ежели писать ГРАМОТНО.

Руслан Сергеевич, извините, но может, сначала все-таки, книжки а уж потом мнения, а?

← →
vuk © (2006-12-11 01:15) [113]

to ors_archangel © (11.12.06 01:08) [110]:
>Значит можно писать
Не все, что можно писать, нужно писать. :)

to Юрий Зотов © (11.12.06 01:08) [111]:
>Какая-такая телепатия? Он уже все сам написал.
Хде? Если тонким слоем по всей ветке, то лично меня это не устраивает. Хочу четкости определений. Да, я сволочь! :))

← →
ors_archangel © (2006-12-11 01:18) [114]

> >По-моему, должна быть возможность расширять описание любого
> >подкомпонента формы.
> Есть два метода расширения функциональности - наследование
> и делегирование (через события). Какой Вы предпочитаете?
> И понимаете ли, что последует за использованием каждого
> из методов?
>

Я имел в виду только расширение описание - свойство добавить, поле, но чтобы не уходить от ответа - то думаю, наследование нужно применять когда оно реально (только не наподать сразу на это слово!) просиходит, а делегирование я понимаю только как множественную обработку событий с помощью делегатов (поправь если не правильно обязательно!), если так мыслить, то мы лучше не предпочитать один метод другому, а использовать их по назначению, и не обленился я совсем, просто не хочется ужастно делать то, что может сделать за тебя компютер, а делать это приходится, и часто :(

// Программы есть для всего, просто они ещё не написаны

← →
ors_archangel © (2006-12-11 01:26) [115]

Всё, извините, пойду читать книжки :)

← →
Cyrax © (2006-12-11 01:30) [116]

В общем, на днях продолжим...
(ors_archangel, к сожалению, сломался)

← →
Vga © (2006-12-11 01:40) [117]

> Мне Васькино высказывание больше нравится

Двусмысленно - смотри мою анкету :)

> >vuk © (08.12.06 01:16) [47]
> >>Нигде в коде этой инициализации нет.
> >В коде она есть. В коде предка-контейнера.
>
> Я говорю об инициализации в коде. Таковой не имеется. Это
> факт.

Имеется. Это интерпретатор DFM, который зарыт где-то в недрах VCL и работает на основе RTTI и TComponent (AFAIK). Вместо того, чтобы плодить инициализационный код, они написали интерпретатор DFM, который в исполняемом файле в одном экземпляре независимо от количества форм и компонентов. Похожая система - DIALOG RESOURCE из WinAPI.

> В этом согласен с Cyrax, может нужно было объединить визуальное
> и невизуальное, любой класс - квадратик с publishedными
> свойствами и наоборот, только не на форме, а отдельно, например,
> выбираешь класс в Explorerе, а в Инспекторе тебе его свойства
> можно редактировать, обработчики назначать.

Зачем лишний механизм, когда уже есть подходящий? Лишний механизм = линшний код в исполняемом файле.

> Обработчики - тоже согласен с Cyrax - совершенно не правильно,
> что отделены от классов, с которыми они связаны, если я,
> допустим, нажимаю на кнопку Button1, я бы хотел, чтобы
> это событие обрабатывалось в TButton1.ClickEvent каком-то
> что ли

Плодить для каждой кнопки новый класс? Это прибавит веса исполняемому файлу и довольно заметно.
> нужно разбираться кто есть Sender,

Зачем, если этот обработчик у тебя привязан только к одной кнопке? Sender требуется, когда один обработчик привязан к нескольким компонентам, а в предлагаемом тобой варианте с TButton1 это невозможно.
> (много хочу, наверно, а ведь в KOL/MCK что-то подобное уже
> есть),

MCK послабее механизм, чем DFM.

← →
vuk © (2006-12-11 01:44) [118]

to ors_archangel © (11.12.06 01:18) [114]:
>расширение описание - свойство добавить, поле,
То есть все-таки наследование. Я правильно понял? Или Вы знаете другой метод расширения "описания"? Так вот, теперь подумайте, что мы получим, если будем плодить наследников по каждому мелкому поводу. Сколько классов будет в приложении? Оправдано ли это будет?

>делегирование я понимаю только как множественную обработку событий
Делегирование - это передача части функций другому объекту. Все.

>с помощью делегатов
Это как в .net? Если да, то учтите, что дотнетовские делегаты - полные аналоги event-ов в VCL. Отличие только в мультикастинге, но это уже особенности библиотеки - в VCL мультикастинга не было изначально, а на существующий механизм его не прикрутить.

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

← →
Vga © (2006-12-11 01:46) [119]

> [114] ors_archangel © (11.12.06 01:18)

> Я имел в виду только расширение описание - свойство добавить,
> поле

Это и есть то, для чего предназначено наследование. Посмотри в потрохах VCL, там повсеместно нечто подобное, например иерархия
TCustomMemoryStream
TMemoryStream
TResourceStream
Есть и другие примеры.

← →
Vga © (2006-12-11 01:48) [120]

> [116] Cyrax © (11.12.06 01:30)

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

← →
Cyrax © (2006-12-11 01:53) [121]

Vga, вот сейчас я отвечу (умеренно агрессивно). Ветку закроют. И только поэтому промолчу...
Или думаешь, всё так просто ? Не всегда. Не в моём случае...

← →
ors_archangel © (2006-12-11 01:53) [122]

Извините ещё раз, но

Feild Form1.Button1 shoudl be of type TButton but is declared as TButton1. Correct the declaration?

каждый раз Делфи будет спрашивать, если

> TButton1 = class(TButton)
> somefield: integer;
> end;
> TForm1 = class(TForm)
> Button1: TButton1;
> end;

Краеугольный камень ООП… Oops - не работает! Так и знал, так и знал, скоро совсем пессимистом стану с этим Delphi IDE!
И книжки читать не надо! (Хотя в какой-то книжке как раз я и прочитал, что нельзя трогать published поля в форме)

← →
ors_archangel © (2006-12-11 01:56) [123]

Если сказать Да, заменит TButton1 на TButton, если нет и запустить, то скажет Class TButton not found
Cyrax, мы их делаем!

← →
vuk © (2006-12-11 02:01) [124]

to ors_archangel © (11.12.06 01:53) [122]:
>Краеугольный камень ООП… Oops - не работает!
А ить я предупреждал! Не все, что можно писать, нужно писать. :)

А в dfm-е что написано? :)

>Cyrax, мы их делаем!
Ох, замучаетесь! :))

← →
ors_archangel © (2006-12-11 02:07) [125]

Поменял в dfm:
Delphi: - Class TButton1 not found! ... Ignore, cancel, ignore all?
ors_archangel: - Ignore
Делф удалил контрол с формы нафиг, а описание оставил, и из dfm - удалил тоже!

> Ох, замучаетесь! :))

Просто чё вы наезжаете зря, мне за вас стыдно, каждого ламером обзовёшь, а с кем общаться-то потом?

← →
Юрий Зотов © (2006-12-11 02:16) [126]

А за каким же хреном заставлять писать в DFM неизвестный класс? Это ж и козе понятно, что не получится.

Говорили же - ежели писать ГРАМОТНО.
type TButton1 = class(TButton) public SomeField: string; end; TForm1 = class(TForm) procedure FormCreate(Sender: TObject); procedure Button1Click(Sender: TObject); public Button1: TButton1; end; procedure TForm1.FormCreate(Sender: TObject); begin with TButton1.Create(Self) do begin Parent := Self; SomeField := "Превед чайникам!"; OnClick := Button1Click end end; procedure TForm1.Button1Click(Sender: TObject); begin ShowMessage(TButton1(Sender).SomeField) end;

PS
Тут кто-то жаловался, что DFM - это плохо, а код - это хорошо. Ну так и работайте кодом, ежели не лень. Никто не мешает.

← →
ors_archangel © (2006-12-11 02:18) [127]

> with TButton1.Create(Self) do
> begin
> Parent := Self;
> SomeField := "Превед чайникам!";
> OnClick := Button1Click
> end

Очень смешно

← →
vuk © (2006-12-11 02:25) [128]

to ors_archangel © (11.12.06 02:07) [125]:
>Class TButton1 not found!
Логично. IDE о нем ничего не знает.

>Просто чё вы наезжаете зря
Цитату в студию, где я на кого-либо наезжал. ;)

>мне за вас стыдно
Не утруждайте себя, оно того не стоит. :))

Даю совет. Только не обижайтесь. Уровень понимания того, что происходит в результате тех действий, которые Вы попытались сделать, у Вас нулевой. Читайте книги, изучайте исходники VCL, лучше с отладчиком. Тогда поймете, что происходило и почему. Еще в понимании сильно помогает самостоятельная разработка компонентов.

← →
vuk © (2006-12-11 02:33) [129]

to Юрий Зотов © (11.12.06 02:16) [126]:
>Говорили же - ежели писать ГРАМОТНО.
Если сделать грамотно, можно и TButton на TButton1 подменить. И работать будет. Главное - потом в IDE не открывать. :)

← →
ors_archangel © (2006-12-11 02:40) [130]

> самостоятельная разработка компонентов

да - это вещь, правда я почему-то слишком много АПИ туда всегда сую, моно было бы больше через ВСЛ делать, но что уж тут поделать... Всё-таки не считаю, что уровень понимания компонентной модели у меня нулевой, если я их могу разрабатывать, - вот ты на меня и наехал vuk :(

← →
Юрий Зотов © (2006-12-11 02:48) [131]

> ors_archangel © (11.12.06 02:40) [130]

> правда я почему-то слишком много АПИ туда всегда сую

Оно и понятно, почему - как раз от слабого знания объектной модели Delphi. Что человек лучше знает - то и юзает, это естественно.

Не знать чего-то, или знать слабо - это нормально, мы все такие. Но на фига ж ругать то, чего толком не знаешь? Это же "Мартышка и очки" получается.

← →
vuk © (2006-12-11 02:54) [132]

to ors_archangel © (11.12.06 02:40) [130]:
>Всё-таки не считаю, что уровень понимания компонентной модели у меня
>нулевой
Тут не только модель нужно знать, но и как все это с IDE взаимодействует. Если бы Вы это все понимали, то не сделали того, что сделали.

>вот ты на меня и наехал
Я не наехал. Я факт констатировал. Если Вы указание на отсутствие некоторых знаний воспринимаете как наезд, то я даже и не знаю... Даваете будем вас гением называть. Легче станет? :))

← →
ors_archangel © (2006-12-11 02:56) [133]

> И даже проблем с очками не будет, ежели носить ГРАМОТНО

← →
Vga © (2006-12-11 02:57) [134]

> [125] ors_archangel © (11.12.06 02:07)

Класс TButton1 надо зарегистрировать в Delphi IDE для использования его в дизайнере форм (и формах, созданных в этом дизайнере). Причем, в Delphi это сделать куда проще, чем в том же Qt (я пробовал... С полпинка не получилось). То есть, дописать процедуру регистрации и установить компонент в Delphi IDE.

← →
ors_archangel © (2006-12-11 03:13) [135]

> Vga © (11.12.06 02:57) [134]

Вариант...

Скажем так, почему все так защищают Делфи, я не понимаю, вот это точно, он - идеален, он - гениален? Я хочу его критиковать, "Творческое мышление, возможно, означает всего-навсего понимание, что нет никакой особой добродетели в том, чтобы вести дела так, как их всегда вели до нас." (Рудольф Флеш)

// И никто не увидит конца этой войны

← →
Eraser © (2006-12-11 03:20) [136]

> [135] ors_archangel © (11.12.06 03:13)

> почему все так защищают Делфи

1. см. название форума.
2. Delphi и Object Pascal - лучшая IDE и язык для написания прикладных программ под платформу Win32.

← →
ors_archangel © (2006-12-11 03:33) [137]

> Eraser ©
> Delphi и Object Pascal - лучшая IDE и язык для написания
> прикладных программ под платформу Win32.

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

← →
Eraser © (2006-12-11 03:39) [138]

> [137] ors_archangel © (11.12.06 03:33)

добрая половина того, что ты перечислил имеется только в Джаве или C#, я не просто так указал win32.

> В Object Pascal нет шаблонов, множественного наследования

и слава Богу, эт я про множественное наследование.

> инлайн-вызовов

есть.

> перегрузки операторов

есть.

> зато есть запрет на циклы в юзасах модулей

и правильно.

← →
ors_archangel © (2006-12-11 03:43) [139]

?
> > инлайн-вызовов
>
> есть.
>
> > перегрузки операторов
>
> есть.

Поясни

← →
Джо © (2006-12-11 03:44) [140]

> [139] ors_archangel © (11.12.06 03:43)
> ?
> > > инлайн-вызовов
> >
> > есть.
> >
> > > перегрузки операторов
> >
> > есть.
>
> Поясни

А что пояснять? Уже два года, как есть.

← →
ors_archangel © (2006-12-11 03:47) [141]

> я не просто так указал win32.
- меня это сбило, всё понятно, не знаю, у меня гллючит новый Делф очень, бета, верняк, какая-нить...
А перегрузка оперов доступна на win32, а как ж там инлайн-вызовы, директива - inline, что ли? просветите, меня, так как у меня оно глючно пока, но если такие фьючи, то можно и релиз искать начинать :)

← →
Eraser © (2006-12-11 04:00) [142]

> [141] ors_archangel © (11.12.06 03:47)

не знаю что у вас там за бета, но у меня BDS2006 - работает вполне стабильно, особенно по сравнению с BDS2005, но временами глючит, этого не отнять )
к слову VS2005 намного стабильнее.
ждемс горца, мож понадежнее будет )

← →
Юрий Зотов © (2006-12-11 08:16) [143]

> ors_archangel © (11.12.06 03:13) [135]

> почему все так защищают Делфи
Неправда. Никто Delphi не защищает. Просто когда люди видят, что человек сказал чушь, то ему объясняют, в чем она заключается. При чем тут какая-то там "защита"?

> Я хочу его критиковать,
Сколько угодно. Только для начала бы не мешало бы как следует ЗНАТЬ то, что критикуешь. А то смешно ведь - "Пастернака не читал, но осуждаю".

← →
ZeroDivide © (2006-12-11 09:29) [144]

- Да не согласен я. - С кем? С энгельсом или с каутским? - С обоими, - ответил Шариков.

В силу эффективности использования кода или его графических аналогов всё исходное "сырьё", служащее для получения законченной программы, должно быть представлено и сохранено в единообразном формате. Во всяком случае это должен быть либо код на каком-либо языке программирования, либо файлы других форматов для графического представления модели будущей программы.
Здесь же у нас часть кода хранится в pas/cpp -файлах, часть - в dfm-ках.

- дело не хитрое. А то что же: один в семи комнатах расселился штанов у него сорок пар, а другой шляется, в сорных ящиках питание ищет.

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

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

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

← →
Kolan © (2006-12-11 09:32) [145]

> ZeroDivide

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

А третьего дня обелись зубного порошку :)

ЛОЛ

← →
Юрий Зотов © (2006-12-11 09:39) [146]

По-видимому, либо человек таким образом собирает материал для чего-то (курсового? диплома? статьи?...), либо имеет какую-то свою парадигму (ООП? построения IDE? проектирования? кодинга?...).

Но в любом случае налицо:
а). совершенно непонятный эпатаж;
б). каша в понятиях.

← →
Anatoly Podgoretsky © (2006-12-11 09:42) [147]

> Cyrax (11.12.2006 01:53:01) [121]

> Vga, вот сейчас я отвечу (умеренно агрессивно). Ветку закроют.

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

← →
Anatoly Podgoretsky © (2006-12-11 09:47) [148]

> ors_archangel (11.12.2006 03:13:15) [135]

> Я хочу его критиковать

Ух ты, а готов аргументировано и грамотно критиковать?
Пока не видно.

← →
Anatoly Podgoretsky © (2006-12-11 09:49) [149]

> Eraser (11.12.2006 03:39:18) [138]

> и слава Богу, эт я про множественное наследование.

Убил Абдула Петруху, это я про C# и медленное убиение С++

← →
Anatoly Podgoretsky © (2006-12-11 09:50) [150]

> ors_archangel (11.12.2006 03:47:21) [141]

> А перегрузка оперов

Оперы и так перегружены, это тебе любой опер скажет

← →
Чапаев © (2006-12-11 09:56) [151]

> Не, ну совсем народ обленился!
Да ладно... Вот когда будет у народа полторы сотни (а после установки JVCL -- и все пять сотен) вкладочек, тогда и сравним, кто обленился: кто перетаскивает со вкладки, или кто руками набирает. ;-D

> В Object Pascal нет шаблонов, множественного наследования
Слава Кришне...

> а). совершенно непонятный эпатаж;
Пардон за критику стиля, но в данном случае точка излишня.

← →
Юрий Зотов © (2006-12-11 10:04) [152]

А что такое "излишня"?

:o)

← →
Чапаев © (2006-12-11 10:10) [153]

> [152] Юрий Зотов © (11.12.06 10:04)
Её там не надо. В принципе, можно выделить три варианта "нумерованного списка":
а) фраза один;
б) фраза два.
-----
1) фраза один;
2) фраза два.
-----
1. Фраза один.
2. Фраза два.

← →
Чапаев © (2006-12-11 10:11) [154]

> три варианта
Три варианта оформления. ;-)

← →
Юрий Зотов © (2006-12-11 10:15) [155]

> Чапаев © (11.12.06 10:10) [153]

а). Просто это слово мне незнакомо.
:o)

б). А можно выделить и еще 33 варианта. И даже 333 - тоже можно. И каждый будет не хуже и не лучше других. Например, этот.

← →
Чапаев © (2006-12-11 10:18) [156]

> [155] Юрий Зотов © (11.12.06 10:15)
Перечисленные мною сертифицированы для применения в русском языке. :*) Оставшиеся тридцать -- для нонконформистов, не способных выучить русский. ;-) Ну и для пламенных борцов со стандартами, конечно.

← →
Юрий Зотов © (2006-12-11 10:30) [157]

> Чапаев © (11.12.06 10:18) [156]

(Мечтательно:) Вот бы еще и ссылку на этот сертификат...

Официальный, конечно. А не "моя левая нога так думает". Потому что у меня левая нога тоже есть. И думает ничуть не хуже.

← →
Чапаев © (2006-12-11 10:31) [158]

> [157] Юрий Зотов © (11.12.06 10:30)
Сам был бы рад иметь такую ссылку. К сожалению, нету. :-(

← →
Юрий Зотов © (2006-12-11 10:33) [159]

Тогда вспоминается анекдот, как медведь пытался летать с вороной...

← →
Kolan © (2006-12-11 10:38) [160]

> [159] Юрий Зотов © (11.12.06 10:33)
> Тогда вспоминается анекдот, как медведь пытался летать с
> вороной...

Гост вроде есть. Нас по нему заставляли делать курсовые. Где то даже лежит дома. Ессно его я не читал...

← →
Vga © (2006-12-11 14:34) [161]

> [137] ors_archangel © (11.12.06 03:33)

В основном либо уже есть (инлайны, перегрузки операторов), либо делается (шаблоны), либо довольно сомнительно (множественное наследование, из Java его например выкинули, а в одной книге по С++ видел - "MFC показывает, что множественное наследование использовать можно, но лучше этого не делать"), насчет делегатов и анонимных методов точно не знаю, хеши - что это? И языковое ли это средство? То, что я понимаю по умолчанию под хэшами - реализуется библиотекой, а не языком.

← →
Vga © (2006-12-11 14:35) [162]

> зато есть запрет на циклы в юзасах модулей

Почитай книги/статьи по теме и подумай, тогда ты поймешь, чем обоснован этот запрет и почему в С/С++ его нет.

← →
MikePetrichenko © (2006-12-11 14:39) [163]

> Какой смысл оформлять классы

Никакого. Да и вообще программирование - бессмысленное занятие. Ведь материальной вещи не создается. Так. Картинки на мониторе, да и то руками не пощупать...

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

P.S. Вот и я присоединился к "пофлудить".

← →
Vga © (2006-12-11 20:44) [164]

> [163] MikePetrichenko © (11.12.06 14:39)

То, что "руками не пощупать" однако не мешает тебе продавать свою библиотеку, и за приличные (для меня) деньги. :)

← →
Cyrax © (2006-12-12 00:11) [165]

1. Сабж
2. dfm-ки без кодового аналога
3. "Delphi и Object Pascal - лучшая IDE и язык для написания прикладных программ под платформу Win32." - смеяться или плакать ?
4. Шаблоны и множественное наследование
5. h/cpp vs interface/implementation

>Anatoly Podgoretsky © (11.12.06 09:47) [148]
>Ух ты, а готов аргументировано и грамотно критиковать?
>Пока не видно.

Будет, Анатолий, будет. Всё будет...
(с VCL"ем проблем не возникло, с этим их тоже не будет)

← →
Anatoly Podgoretsky © (2006-12-12 00:14) [166]

> Cyrax (12.12.2006 0:11:45) [165]

Ну тогда я спокоен.

← →
Vga © (2006-12-12 00:30) [167]

> [165] Cyrax © (12.12.06 00:11)

1) Визуальная разработка. Delphi же RAD-среда. Она в первую очередь ориентирована именно на визуальное проектирование.
2) Ну и зачем он им?
3) Все вместе. Утверждение действительно спорное. По крайней мере, без указания критериев оценки.
4) Первое - есть, второе - даже из некоторых наследников С++ выкинули.
5) Мож мне кто-нить укажет достоинства первого по сравнению со вторым? Не вижу.

← →
vuk © (2006-12-12 00:38) [168]

to Vga © (12.12.06 00:30) [167]:
>5) Мож мне кто-нить укажет достоинства первого по сравнению со вторым?
>Не вижу.
Вот-вот. Наличие модульности всяко лучше её отсутствия. :)

← →
Cyrax © (2006-12-12 00:45) [169]

Vga, список тех вопросов требует отдельного детального рассмотрения... под моим контролем...
Насчёт 5-го пункта: вижу, тебе интересно, какие аргументы я приведу...

← →
Vga © (2006-12-12 00:51) [170]

> [169] Cyrax © (12.12.06 00:45)

Не ты. Кто-нибудь более знающий.

← →
isasa © (2006-12-12 00:56) [171]

Cyrax © (12.12.06 00:11) [165]

5. h/cpp vs interface/implementation

А попробуй подключи COM объкты через idl по схеме h/cpp(с автогенерацией этих *.h и *.c), а потом избавиться от duplicate declaration _IID_Class ... :)

← →
Юрий Зотов © (2006-12-12 02:06) [172]

Интересный спор, однако.

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

Куча других челов говорит ему: "слушай, а чем и почему это плохо?".

Игнорирует. Просто пропускает мимо ушей, совершенно никак не реагируя. А потом, немного выждав, снова свое - это плохо.

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

Тоже игнорирует. Тоже просто пропускает мимо ушей, совершенно никак не реагируя. А потом - снова свое: это плохо.

В результате действо сильно напоминает дискуссию с бульдозером. Но тогда возникает простой вопрос: а это не глупо - бульдозеру что-то объяснять и доказывать? Не приберечь ли бисер-то?

Пожалуй, приберечь. Попробовали - ну и хватит.

← →
Eraser © (2006-12-12 03:20) [173]

> [172] Юрий Зотов © (12.12.06 02:06)

> В результате действо сильно напоминает дискуссию с бульдозером.
> Но тогда возникает простой вопрос: а это не глупо - бульдозеру
> что-то объяснять и доказывать? Не приберечь ли бисер-то?

см. [30]

← →
Юрий Зотов © (2006-12-12 03:39) [174]

> Eraser © (12.12.06 03:20) [173]

И правда.

← →
Чапаев © (2006-12-12 08:44) [175]

> смеяться или плакать ?
Поплачь, писять меньше будешь.

> [172] Юрий Зотов © (12.12.06 02:06)
http://redeyes.ru/panopticum/zhelezyakin/zhelezyakin.shtml

Где-то тут была ссылка на БиоРеактор.
Да и:
"Никогда не спорь с дураком, люди могут не заметить между вами разницы" (С) К. Прутков

я этого не далю
классы - они и есть классы.

to Юрий Зотов © (12.12.06 02:06) [172]:
>Тогда куча других челов начинает доказывать ему, что это не плохо, а,
>наоборот, хорошо.
Тут такое дело. Если сравнивать Two Way и ресурсы в dfm, то, на мой взгляд, получится, что Two Way таки лучше. Проблем меньше в результате. По себе сужу. Мы активно используем в проектах фреймы. Их главный минус в том, что если меняем фрейм, то часто приходится "протаскивать" изменения через все фреймы, в который вложен измененный и так далее по дереву. Был бы Two Way, таких проблем не было бы, т.к. все свойства расписаны один раз, а не будут повторяться в dfm-е чуть ли не при каждом вложении фрейма.

Проблема именно в механизме dfm и невозможности им управлять. Если бы управление было возможно, с удовольствием запретил бы запись в dfm свойств вложенных фреймов.

>запретил бы запись в dfm свойств вложенных фреймов
Поправлю себя. Правильнее было бы сказать так: "запретил запись компонентов, расположенных на вложенных фреймах". То есть, если фрейм A вложен во фрейм B, то в dfm фрейма B попадали бы свойства самого фрейма A, но не компонентов на нем.

> vuk © (12.12.06 12:23) [179]
>
> >запретил бы запись в dfm свойств вложенных фреймов
> Поправлю себя. Правильнее было бы сказать так: "запретил
> запись компонентов, расположенных на вложенных фреймах".
> То есть, если фрейм A вложен во фрейм B, то в dfm фрейма
> B попадали бы свойства самого фрейма A, но не компонентов
> на нем.

Мы тоже активно юзаем фреймы. Я бы ни в коем случае не запрещал.

Их главный минус в том, что если меняем фрейм, то часто приходится "протаскивать" изменения через все фреймы, в который вложен измененный и так далее по дереву.

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

to ZeroDivide © (12.12.06 12:54) [180]:
>Т.е. не вкладывать фреймы в фреймы, а наследовать фреймы расширяя их
>функциональность?
Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.

ЗЫ: Фреймы вообще уникальная вещь, ни в каких других языках и IDE нет ничего подобного по функциональным возможностям. Подобное есть, но до Borland"овского TFrame - не дотягивает.

Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.

Почему?

to ZeroDivide © :
>Фреймы вообще уникальная вещь
Составной компонент. Ничего уникального.
По идее, и использование такое же - накромсали кирпичиков прикладного уровня и используем. Только вот ведет он себя не совсем так, как компонент в части сохранения свойств. Конечно, из этой ситуации есть выход. Нужно просто покидать фреймы в пакет и зарегистрировать в IDE.Тогда в dfm попадут только свойства самого фрейма. Но это уже существенно замедляет разработку, да и палитра компонентов лопнет от перекорма.

>ни в каких других языках и IDE нет
>ничего подобного по
>функциональным возможностям.
Копался в .net, есть там пользовательские контролы. Использовать их можно прямо в том проекте, где они определены. Всем бы хорошо, только мы-то не под .net.

>Нелогично.
>Почему?
Ровно по той же причине, по которой TDBGrid не является наследником TDataSet.

Конечно, из этой ситуации есть выход. Нужно просто покидать фреймы в пакет и зарегистрировать в IDE.Тогда в dfm попадут только свойства самого фрейма.
Угу... и придеться отказаться от визуального наследования фреймов... нет уж... + еще несколько существенных проблем. Мы отказались от этой идеи.

Копался в .net, есть там пользовательские контролы. Использовать их можно прямо в том проекте, где они определены. Всем бы хорошо, только мы-то не под .net.

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

>Пример. Стандартная ситуация - Master/Detail. Есть фрейм для Detail (используется в нескольких местах). Расширять его, впихивая в него Master? Нелогично.
>Почему?
Ровно по той же причине, по которой TDBGrid не является наследником TDataSet.

Как раз все наоборот "Ровно по той же причине, по которой TDBGrid не является наследником TDataSet." можно от него унаследоваться и расширить его еще одним гридом. Мы же не от грида наследуемся, а от фрейма содержащего грид.

У нас есть один такой базовый фрейм: Справа DBTree слева DBGrid... При открытии ветки дерева DBGrid отбирает соответствующие записи. Наследован от фрейма в котором есть только DBGrid... Вполне красиво и юзабельно.

Немного концепции... можно сделать фрейм-предок типа TfrmGridsContainer и научить его управлять положенными на себя умеющимися управляться фреймами типа TfrmUserGridView с гридами. Затем что-то типа TfrmGridsMasterDetailContainer, наследник от TfrmGridsContainer, который бы и реализовывал m-d связь. А TfrmUserGridView был бы наследником от TfrmBasicUserGridView, содержащий общую для просмотра всех таблиц функциональность. (Это упрощенная модель)

> [175] Чапаев © (12.12.06 08:44)
> > [172] Юрий Зотов © (12.12.06 02:06)
> http://redeyes.ru/panopticum/zhelezyakin/zhelezyakin.shtml

Хм, точно Железякин! :)

Начало -> если А -> то А -> результат А -> конец.
Начало -> если Б -> то Б -> результат Б -> конец.

Любые твои попытки перейти на фортран или бейсик (не говоря уж о С++) ведут к сбою цепочки Железякина и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Любая новая информация, привносимая извне, приравнивается Железякиным к сбою цепочки и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Ты можешь блестяще (как тебе кажется) опровергнуть любой из его доводов. Это приравнивается Железякиным к сбою цепочки и ее демонстрации с самого начала по-новой - без какого-либо апгрейда.

Ты можешь потрясающе глубоко и остроумно проанализировать психологические причины зацикливания Железякина на своем любимом алгоритме. Это приравнивается Железякиным к сбою цепочки и... ну, ты понял.

to ZeroDivide (12.12.06 16:24) [185]:

>Угу... и придеться отказаться от визуального наследования фреймов...
Внутри пакета - наследуйтесь сколько хотите.

>В UserControl нельзя перемещать контролы базового класса
>и вешать на них обработчики в дизайнере...
И правильно. Навешивание обработчика на вложенный контрол является
нарушением инкапсуляции. Хотите обработчик - выводите наружу event. К тому же в Delphi всё назначение обработчиков вложенных контролов после операции "Revert to inherited" отправляется в dev/null. А к операции этой иной раз приходится прибегать, т.к. иногда изменения в фреймах ну никак не хотят отображаться в тех местах, где фреймы используются, иногда бывает хуже, и некоторые проблемы лечатся только удалением фрейма целиком и складыванием его назад. И тут либо нужно помнить, что, кому и зачем прописывалось (угу, через пару-тройку лет) либо прописывать их руками в коде инициализации.

>Вполне красиво и юзабельно.
Прокатывает все это дело только в элементарных случаях, поскольку не дает
возможности строить приложения из готовых функциональных "кирпичиков", т.к. если где-то есть что-то похожее/аналогичное, но унаследовать уже нельзя то остается только copy/paste. Либо все-таки складывать готовые фремы и иметь в виду что будут некоторые проблемы. Я не знаю, как у вас, но мы предпочитаем иметь некоторые проблемы, но обойтись без copy/paste.

>Это упрощенная модель
Мда... если это упрощенно... Вообще говоря, у нас чаще всего весь Master/Detail обходится в одно событие у Master и одно свойство у Detail (ну, еще иногда обртная связь бывает нужна). Безо всяких заморочек. Большинство фреймов (в основном проекте их больше 700, форм меньше раза в три) содержат всю нужную им функциональность и расширения не требуют.

Отвлекаясь от этого случая, задумайтесь вот над чем. Как вообще происходит разработка приложения на Delphi? Кликнули - создали форму. Кликнули - положили на нее меню. Кликнули - создали набор action-ов. Кликнули несколько раз - создали сами action-ы (и все кликами - и картинку им выбрать, и обработчик создать, пока что пустой). Кликнули несколько раз - накидали элементов в меню. Каждому элементу сопоставили action - тоже кликами. Кликнули - ... Кликнули - ... Кликнули - ... ... ...

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

http://skipy.dev.juga.ru/philosophy.html

> [188] Ученик чародея © (12.12.06 21:50)
> Отвлекаясь от этого случая, задумайтесь вот над чем. Как
> вообще происходит разработка приложения на Delphi? Кликнули
> - создали форму. Кликнули - положили на нее меню. Кликнули
> - создали набор action-ов. Кликнули несколько раз - создали
> сами action-ы (и все кликами - и картинку им выбрать, и
> обработчик создать, пока что пустой). Кликнули несколько
> раз - накидали элементов в меню. Каждому элементу сопоставили
> action - тоже кликами. Кликнули - ... Кликнули - ... Кликнули
> - ... ... ...

Это всего лишь одна часть работы, для меня — ничтожная по сравнению со временем, потраченным на остальными задачи.

> Кликнули - создали форму. Кликнули - положили на нее меню.
> Кликнули - создали набор action-ов.
Ну можно всё это произвести вручную. Только кому это нафиг надо? В большинстве случаев неоправданная трата времени.

>>Джо © (12.12.06 21:54) [189]

Человек, Java - программист считает, что если делфист - значит ламер. Я пытался оспаривать - логические доводы не действуют:

http://forum.juga.ru/showthread.php?s=&threadid=13376

> Я пытался оспаривать
Себе дороже выйдет. Охота ж нервы себе портить...

Стандартное мнение тех, кто разглагольствут о том, чего не знает. Ничего нового.

И правильно. Навешивание обработчика на вложенный контрол является
нарушением инкапсуляции.
:) И давно?

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

Мрак... Тоже не знаю, как вы там используете фреймы, но видимо не лучшим образом. У нас таких проблем не возникает. Хотя в нашей парадигме код инициализации так же приходится ручками прописывать, т.к. если фреймы не в пакете (как я уже говорил, мы отказались), то published-свойства писать бесполезно, они не видятся в инспекторе объеков, для фреймов-наследников :( Это в нашей парадигме - единственная неприятность, связанная с фреймами. Впрочем, тоже решаемая - компоненты лежащие на фремах показывают свои published property и достаточно много можно переложить на компоненты, а иерархии фреймов оставить только роль визуальной иерархии.
Да и писать обычно приходится не очень много, не больше чем:

constructor TfrmXXXX.Create(AOwner: TComponent); begin inherited; Title := "Имя фрейма"; ClassEditForm := TfmXXXXEdit ClassQueryForm := TfmXXXXQuery //Если фрейм вызван как справочник if IsDictionary then begin ..... end; //Если зашли сюда с TfrmYYYYYY, то производим определенные действия if (fmMain.ActiveFrame is TfrmYYYYYY) then begin // допонительная фильтрация (как пример) InsertFilterConditionToDataset(WDM.odsWorkers, "(DISMISS_DATE is null)"); ... end; end;

Все остальное настраивается в инспекторе.

Прокатывает все это дело только в элементарных случаях, поскольку не дает
возможности строить приложения из готовых функциональных "кирпичиков",
Дает. Этих самых "элементарных случаев" не так уж и много для всех возможных UI для всех видов реляционных отношений.

Я не знаю, как у вас, но мы предпочитаем иметь некоторые проблемы, но обойтись без copy/paste.

Аналогично.

Мда... если это упрощенно... Вообще говоря, у нас чаще всего весь Master/Detail обходится в одно событие у Master и одно свойство у Detail

У нас в вызовом одной функции (правда с кучей параметров).

Большинство фреймов (в основном проекте их больше 700, форм меньше раза в три)
У нас тоже фреймов не меньше в некоторых проектах, но все они наследники от базовых фреймов из нашей иерархии и фактически, все что нужно: выбрать подходящего предка и настроить его на работу с определенными данными. Повторюсь: вариантов UI для всех видов реляционных отношений - не так уж и много. У нас порядка 30 базовых фреймов всего. БД клиенты собирать полностью из "кирпичиков" - реально.

ZeroDivide © (13.12.06 01:29) [195]:
>И давно?
Изначально. Работа с объектом должна вестись через его свойства и методы. Навешивая снаружи что-либо на вложенные объекты мы можем нарушить работу внутренних механизмов. К тому же это ведет к ситуации, когда клиенты объекта завязаны на его внутреннюю реализацию.

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

>Тоже не знаю, как вы там используете фреймы, но видимо не лучшим
>образом.
Нормально используем. Штатно. А как - я уже сказал. Фреймы - это составные компоненты, и по большей части каждый из них функционально завершен. Сложные фреймы собираются в дизайнере из простых и тогда функциональность сложных заключается в том, что они являются "клеем" для более простых и координируют их работу. Все навешиваемые на фреймы обработчики прописываются руками, благо их обычно мало, штук 5 - это уже много. Ситуации проблемные возникают крайне редко. Связаны, в основном, с тем, как вложенность фреймов сохраняется в dfm.

← →
test2 (2006-12-13 03:47) [197]

test

> Изначально. Работа с объектом должна вестись через его свойства
> и методы. Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов. К тому же
> это ведет к ситуации, когда клиенты объекта завязаны на
> его внутреннюю реализацию.

Бред.

Работа с объектом должна вестись через его свойства и методы.

Она так и ведется. А то, что объект может обладать свойствами объектного типа - никоим образом инкапсуляцию не нарушает. И доступ к свойствам объекта вида Object.Property1.Property2.Event1 - вполне нормально для ООП.
Пример:
frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").AsInteger;
Или у вас это выглядит, как
frmGridView.FieldByName("ID").AsInteger;
:)
?

Навешивая снаружи что-либо на вложенные объекты
> мы можем нарушить работу внутренних механизмов.
Опять же, скорее наоборот: навешивая изнутри что-то мы можем нарушить работу предполагаемого поведения наших объектных пропертей. Хотя и в том и другом случае мы можем нарушить, а можем и не нарушить.
Пример: повесить обработчик события на вложенный компонент при инициализации фрейма, если при этом не написать код сохрания и вызова обработчика установленного разработчиком фрейма-потомка в инспекторе, то этот обработчик пойдет лесом... А если программер захочет повесить обработчик в рантайм? ... Тогда лесом пойдет обработчик, который повесил фрейм. В общем, как раз такое - делать нельзя!

>Сложные фреймы собираются в дизайнере из простых

Да... не лучшим образом.

1. На вложенных фреймах не будут работать наследники TComponentEditor
2.
>Связаны, в основном, с тем, как вложенность фреймов сохраняется в dfm.

3. Еще что-то... уже не помню (но есть)

Мы пришли к тому, что сделали из фреймов простое дерево, без вложенности веток друг в друга... в некоторых случаях пришлось пожертвовать уникальностью кода, копируя многие участки кода из одних веток этого дерева в другие, создавая в ветках повторяемые UI элементы...
Да, такую парадигму сделать и поддерживать, наверное сложнее... но только "трогать" базовые фреймы уже давно не приходится. Зато безглючность, гибкость, юзабельность вот этой получившейся основы - великолепная, куда выше чем была вкладывая фреймы друг в друга. Натуральный "Кирпичизм" получился: кода писать не надо, все возможные варианты интерфейса - уже написаны в базовых фреймах.
Остается писать бизнес-логику на стороне сервера... но это другая тема....

ZeroDivide © (13.12.06 09:42) [200]

> > Изначально. Работа с объектом должна вестись через его
> свойства
> > и методы. Навешивая снаружи что-либо на вложенные объекты
>
> > мы можем нарушить работу внутренних механизмов. К тому
> же
> > это ведет к ситуации, когда клиенты объекта завязаны на
>
> > его внутреннюю реализацию.
>
>
> Бред.

Почему бред, не затруднит пояснить ?

> Почему бред, не затруднит пояснить ?

А до конца дочитать пост?
(И еще перед эти желательно несколько постов.)

ZeroDivide © (13.12.06 11:10) [204]

Я читать умею, спасибо. Но мне все-таки интересно, почему к процитированному относится слово "бред".

> Пример:
> frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").
> AsInteger;

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

to ZeroDivide © (13.12.06 09:42) [200]:
>Бред.
Ну-ну. :)

>А то, что объект может обладать свойствами объектного типа - никоим
>образом инкапсуляцию не нарушает.
И давно вложенные компоненты своствами стали?

>И доступ к свойствам объекта вида Object.Property1.Property2.Event1 -
>вполне нормально для ООП.
А вот это - действительно свойства. У Вас налицо путаница в понятиях компонентных свойств и вложенных компонентов.

>Или у вас это выглядит, как
>frmGridView.FieldByName("ID").AsInteger;
Нет, вот так мне точно в голову не придет написать. Если нужен доступ к данным к поля (редко), у фрейма делается свойство, с именем, совпадающим с именем поля и с типом данных, соответствующим реальному типу данных. И даже если нужно будет возвращать значение любого поля, то скорее будет свойство типа FieldValues[FieldName: string]:Variant, но никак не свойство, возвращающее ссылку на компонент. Ибо нефиг.

>На вложенных фреймах не будут работать наследники TComponentEditor
Неправда. Работают. Только, опять же, нужды в них нет.

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

> И давно вложенные компоненты своствами стали?

Хорошо. Действительно, вложенные компоненты - поля. Доступ к полям, в том числе и объектных типов, может быть описан через read/write - через свойства. Вряд-ли вы не поняли, что я имел в виду и без уточнения в терминологии.

Но ни когда не задумывались, почему Borland сделал так, что при помещении компонента на фрейм поле добавляется в published, вместо того, чтобы кинуть его в protected и описать published property? Подумайте...

Если нужен доступ к данным к поля (редко), у фрейма делается свойство
И зачем?

Инкапсуляция (encapsulation) - это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый "чёрный ящик".

Вложенные компоненты - это published поля. Делая дополнительные свойства, вы просто сделаете более удобным доступ... но вряд ли он будет более наглядным (очень сомнительно, т.к. этот фрем может быть унаследован и dbGrid"ов и списков полей в наследнике может стать несколько) и с точки зрения защиты, подразумевающейся в инкапсуляции (я думаю вы как раз это имеете в виду под нарушением инкапсуляции), вы не сколько не защищаете, т.к. published.

> Но ни когда не задумывались, почему Borland сделал так,
> что при помещении компонента на фрейм поле добавляется в
> published, вместо того, чтобы кинуть его в protected и описать
> published property? Подумайте...

Для загрузки значений свойств из dfm ? Я угадал и мне положен приз ?

> Для загрузки значений свойств из dfm ? Я угадал и мне положен
> приз ?

Мог бы сделать загрузку protected полей из dfm, если бы помещал поля вложенных свойств в protected, но помещает все таки их в published. (Про RTTI я говорить не буду, но там тоже в таком случае можно было бы все грамотно разрулить).

... И все таки в published :)

Думаю основная возможность такой реализации заключалась в том, что объектные типы сами внутри себя защищены и прямое обращение к ним, если даже они объявлены в publised... не вызывает проблем защиты данных.

to ZeroDivide © (13.12.06 12:20) [207]:
>Но ни когда не задумывались, почему Borland сделал так, что при
>помещении компонента на фрейм поле добавляется в published, вместо
>того, чтобы кинуть его в protected и описать published property?
>Подумайте...
Я не то чтобы задумывался. Я точно знаю зачем. Игорь уже сказал. :) Радикальное отличие компонентных свойств от published полей ещё и в том, что работа свойств как правило классами контролируется через методы доступа, а вот с published полями все не так.

>вы просто сделаете более удобным доступ...
В первую очередь я уменьшаю зацепление и отделяю интерфейс класса от реализации. А уже потом это становится удобным.

>и с точки зрения защиты, подразумевающейся в инкапсуляции вы не
>сколько не защищаете, т.к. published
Согласен здесь есть дыра, но я предпочитаю ей не пользоваться.

to ZeroDivide © (13.12.06 12:41) [209]:
>Мог бы сделать загрузку protected полей из dfm
Мог бы, да не сделал. Реализация RTTI не позволяет. Ну лопухнулись чутка. :)

>прямое обращение к ним, если даже они объявлены в publised... не
>вызывает проблем защиты данных.
frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").Free;
Усё.

> Подобное есть, но до Borland"овского TFrame - не дотягивает.

Дотнетный UserControl дотягивает и перетягивает.

frmGridView.DBGrid.DataSource.DataSet.FieldByName("ID").Free;
Усё.
?

Ну Button1.Free... и чего.. это не доказательство проблем защиты. Может я захотел кнопки поубивать... Почему бы и не поубивать что-нибудь у чего нет visible :)

>На вложенных фреймах не будут работать наследники TComponentEditor
Неправда. Работают. Только, опять же, нужды в них нет.

Сделай фрейм, положи в него TToolBar, положи этот фрейм в другой фрейм... и попробуй в дизайн-тайме на этом тулбаре вызвать "New Button"... получиться? :)

> > Подобное есть, но до Borland"овского TFrame - не дотягивает.
>
>
> Дотнетный UserControl дотягивает и перетягивает.

Ну про "дотягивает" я уже писал. Я не нашел возможности реализовать с помощью UserControl, то что у меня реализовано с помощью TFrame. (Искал хорошо)

А про "перетягивает" хотел бы услышать подробнее...

Удалено модератором

> Юрий Зотов © (13.12.06 01:06) [194]
>
> Стандартное мнение тех, кто разглагольствут о том, чего
> не знает. Ничего нового.

Человек довольно грамотный Java программист, хотя в Delphi ничего не понимает, но берется сравнивать.

> Ученик чародея © (13.12.06 14:39) [217]

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

В общем, сплошное "Мартышка и очки". Ничего нового.

> > Ученик чародея © (13.12.06 14:39) [217]

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

И правильно его там в лужу посадили, когда он полный бред вспорол (что, мол, для невизуального компонента обязательно нужна форма, иначе его и положить некуда). А он, вместо того, чтобы тихо умыться и пойти читать книжки, наезжать на парня начал. Мол, да сколько лет ты пишешь, да имел ли дело с Delphi 1, да какие твои заслуги, если ты использовал кем-то написанный компонент - и пр. Блин, а ты использовал кем-то написанную DLL - ну и какие твои заслуги, чего ты пальцы-то гнешь?

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

Хотел ему все это там же и высказать, да регистрироваться влом было. Можете дать ему ссылку на этот пост, если тоже не лень.

> И когда им рассказывали о том, что же такое Delphi на самом
> деле, то у них от удивления глаза на лоб лезли
Ух... Найти "явистов, сишников и прочих", способных выслушать "что же такое Delphi на самом деле" -- само по себе задача нетривиальная. ;-)

Кстати, обычно вменямыми оказывались именно те "сишники, явисты и пр". кто действительно разбирался в Си, Джаве, да и вообще в программировании.

А НЕвменямыми - именно те, кто, как постепенно выяснялось, ни в Си, ни в Джаве, да и вообще в программировании не шибко-то и рубили.

Зато как наезжали... как пальцы гнули... вот уж точно - ламеры.

> А наезжающих на С можно рассортировать ? Ну хотя бы по этому
> сайту

А точно также. Вменяемые на С не наезжают.

> Игорь Шевченко © (13.12.06 17:05) [224]

Не встречал, сортировать некого. Может, такие и были, но здесь их быстро на место ставят.

to ZeroDivide © (13.12.06 13:17) [214]:
>Может я захотел кнопки поубивать... Почему бы и не поубивать что-нибудь
>у чего нет visible
Если по-нормальному делать, то фрейм сам должен прибивать то, чем владеет.

>Сделай фрейм, положи в него TToolBar, положи этот фрейм в другой
>фрейм... и попробуй в дизайн-тайме на этом тулбаре вызвать "New
>Button"... получиться? :)
То, что на внедренный фрейм нельзя добавлять компоненты не означает, что

> ZeroDivide © (13.12.06 09:42) [200]
> "На вложенных фреймах не будут работать наследники TComponentEditor"

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

Юрий Зотов © (13.12.06 17:14) [226]
Игорь Шевченко © (13.12.06 17:05) [224]

Дятьки старые... :)

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

to ZeroDivide © (13.12.06 18:19) [228]:
>А вот компонент-едиторы не
>работает...
Повторяю еще раз. Еще раз... Редакторы компонентов работают. Ра-бо-та-ют... Я проверял. Про-ве-рял...
:)

> ZeroDivide © (13.12.06 18:26) [229]

30 лет человеку. Профессиональный программист с немалым стажем.

Казалось бы, пора уже...

> Ра-бо-та-ют... Я проверял. Про-ве-рял...

И пример с ToolBar"ом п-р-о-в-е-р-я-л? :)

Юрий Зотов © (13.12.06 19:03) [231]
Профессиональный программист

Это вы про кого?? Про этого чтоли? http://skipy.dev.juga.ru/?philosophy/visualDesigners.html

Либо придется самому организовывать цикл обработки сообщений, что ничуть не проще

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

> jack128 © (14.12.06 10:37) [233]

:-) Я смог дочитать только до слов "Однако для того, чтобы использовать компоненту - нужна форма, на которую эту компоненту нужно положить.", дальше читать не смог, разрыдался...
> ZeroDivide © (13.12.06 18:26) [229]

> Вот научатся эти ламеры и тогда увидите... кто будет лучшими
> специалистами

Они, обычно, становятся ламерами по продаже памперсов.

to ZeroDivide © (14.12.06 09:53) [232]:
>И пример с ToolBar"ом п-р-о-в-е-р-я-л? :)
Вам что, все по два раза нужно повторять? :)
У toolbar не работает по причине невозможности добавления компонентов на внедренный фрейм. Но это не означает, что редакторы компонентов не работают. Я же уже об этом написал в [227].

to Чапаев © (14.12.06 10:45) [234]:
>Ещё б аффтар (модераторы, пардону просю!) объяснил какие такие
>"события приложения" сокету нужны...
А вот нужны. Вы, кстати, исходники scktcomp.pas смотрели? И окно там скрытое есть, и обработка сообщений.

Вот тут нарисовали проблемку с вложеностью контроло
http://www.delphikingdom.ru/asp/answer.asp?IDAnswer=47625

Какие мысли?

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

"В последнее время наметилась одна тенденция. Дело в том, что сейчас для того, чтобы выйти на рынок программных средств и занять в нём свою нишу, фирма, а, соответственно, и программисты должны делать продукт как можно быстрее. При этом, естественно, достаточно часто вопросы эффективности, быстродействия, минимизации размера используемой памяти и тому подобные во внимание просто не принимаются. Зачем, дескать, думать о таких «мелочах», если современные компьютеры достаточно мощные и «переваривают» почти любые объёмы. Подумаешь, мегабайт памяти туда, мегабайт сюда… Кроме того, очень сильное влияние на квалификацию программистов оказывают многочисленные средства быстрой разработки, бурное развитие которых наблюдается в последнее время. Средства, предназначенные для повышения производительности труда квалифицированных программистов, заняли на рынке совершенно другое место. Достаточно часто эти средства используются программистами низкой квалификации для того, чтобы в кратчайшее время создать работающую программу, прикладывая при этом минимум усилий. Более того, средства быстрой разработки позволяют программисту скрыть недостаток квалификации, ибо вся черновая работа делается без участия программиста. Вместо того, чтобы овладеть необходимым для профессиональной деятельности минимумом, можно недостаток квалификации скрыть посредством использования программы, которая всё сделает сама. Таким образом, средства быстрой разработки используются превратились в средства создания неэффективных программ неквалифицированными программистами. Что поделаешь, рынок диктует свои условия…

Соответственно, такой подход приводит к тому, что достаточно часто у программистов появляется завышенная самооценка. Раз я могу «накропать» программу за неделю, значит, я – ВЕЛИКИЙ ПРОГРАММИСТ, всё умею, всё могу. Зачем мне чему-то учиться, я (при помощи конкретного средства) всегда сделаю то, что хочу! Появилось даже расхожее определение – «программист, пишущий мышкой»… Но стоит у подобных, с позволения сказать, программистов, забрать средство быстрой разработки, как они становятся беспомощными. Ведь они являются программистами на конкретном средстве! Другими словами, они являются ПОЛЬЗОВАТЕЛЯМИ конкретного средства… А пользователи и программисты – это совершенно различные классы людей, использующих компьютер в своей профессиональной деятельности. И если пользователю необходимо знать только порядок использования и взаимодействие частей одной или нескольких программ (WinWord, бухгалтерская или банковская программы, программа обработки изображений и так далее), то программист помимо всего прочего должен, почти обязан понимать то, как функционирует компьютер, на основе каких принципов построена операционная система, понимать принципы организации данных и быть в состоянии написать эффективную программу, решающую поставленную перед программистом задачу. В том случае, если программист является профессионалом, то использование средств быстрой разработки только поможет ему, позволив сократить время, необходимое для разработки программы, и минимизировать усилия, необходимые для разработки таковой. "

http://www.techbook.ru/rumyantsev.html

Гм... Действительно, наворотили там такого. Тем не менее, требовать форму для размещения компонента -- этог уж загнул.

>Ю jack128 © (14.12.06 10:37) [233]

Да, Жень, ты прав, я выразился неточно. Надо было написать "профессиональный Java-программист".

:о)

Вообще, могут ли быть сомнения, что практически любой программист, использующий ООП, вместе с ним использует и классы, написанные не им, а кем-то? Вряд ли приходится в этом сомневаться (и уж где-где, а как раз в Java набор таких библиотек весьма велик).

Экземпляры этих классов можно создавать ручками, написав в коде вызов конструктора и присвоение нужных значений свойств. А можно использовать какие-то визуальные редакторы (которые, по сути, приводят к тому же самому).

Что лучше, что хуже? В общем случае, код, сгенеренный редактором, видимо, будет менее эффективным, чем написанный человеком (ну не обладает робот искусственным интеллектом, ну не в состоянии он распознать особенности задачи). Но точно так же при прочих равных (то есть, если уметь пользоваться редактором так же хорошо, как писать код), использование редактора, видимо, экономит время разработчика. По крайней мере, в IDE Delphi - экономит точно. И экономит ОЧЕНЬ сильно.

Это недостаток? ИМХО, это достоинство. Если тебе нужна эффективность - пиши ручками, никакой редактор этого не запрещает. А если на первый план выходит время разработки (что бывает очень и очень нередко) - то почему не использовать инструмент, для того специально и предназначенный?

Поэтому называть такой подход перенебрежительным термином "мышекликательное программирование" есть, ИМХО, не что иное, как снобизм.

to Чапаев © (14.12.06 11:49) [240]:
>Действительно, наворотили там такого.
Да нет, просто такой режим работы сокетов, где используются сообщения окну. В Indy, например, такой режим не используется.

> vuk © (14.12.06 11:36) [236]

> У toolbar не работает ...

> по причине невозможности добавления компонентов на внедренный
> фрейм

Пусть так... для меня было критично, что не работает у тулбара... Хорошо... пусть будет: "Во вложенных фреймах, наследники TComponentEditor работают, но не для всех компонентов из стандартной палитры VCL".

> Вот тут нарисовали проблемку с вложеностью контроло
> http://www.delphikingdom.ru/asp/answer.asp?IDAnswer=47625
>
> Какие мысли?

Попробовать отписать в QC, послушать, что они скажут.
Я воспроизвел эксперимент с панелями. В результате у меня 13 вложенных панелей поддержали Align=alClient, а 14-я уже нет... :)

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

to ZeroDivide © (14.12.06 13:33) [243]:
>"Во вложенных фреймах, наследники TComponentEditor
>работают, но не для всех компонентов из стандартной
>палитры VCL"
Опять неправильно. Редактор компонента работает, но не добавляет пенкт в меню, если смысла в этом пункте нет никакого.

> Опять неправильно. Редактор компонента работает, но не добавляет
> пенкт в меню, если смысла в этом пункте нет никакого.

Согласен. Рму руку. Правда... кхм... кхм... все же, смысл есть, поддержки со стороны вложенных фреймов нет.

Собственно разговор-то начался именно с этого. Т.к. в иерархии - компоненты добавлять на унаследованные от предка - можно :)
И это +

> Юрий Зотов © (13.12.06 15:52) [219]
> И правильно его там в лужу посадили, когда он полный бред
> вспорол (что, мол, для невизуального компонента обязательно
> нужна форма, иначе его и положить некуда). А он, вместо
> того, чтобы тихо умыться и пойти читать книжки, наезжать
> на парня начал. Мол, да сколько лет ты пишешь, да имел ли
> дело с Delphi 1, да какие твои заслуги, если ты использовал
> кем-то написанный компонент - и пр. Блин, а ты использовал
> кем-то написанную DLL - ну и какие твои заслуги, чего ты
> пальцы-то гнешь?

Ну так Ученик чародея и AlifeSoft одно и то же лицо :)

Это было понятно...
:о)

to ZeroDivide © (14.12.06 15:27) [247]:

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

А что касается вложенности окон и неприхода сообщений, то это, похоже, глюк Windows.

Какой смысл оформлять классы, не имеющие... Найти похожие ветки