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

Уточняю. Если нужно один и тот же обработкик для двух разных контролов, то придется его заносить в каждый контрол по отдельности, через Copy&Paste?

>>> DataWindow из PB будет перекрывать одновременно по возможностям и
>>> кач-ву тот же DexExpress QGrid и FastReport вместе взятые

Неужели DataWindow может заменить генератор отчетов? Вы не погорячились? Как вы, например, будете под ним какую-нибудь стандартную форму счет-фактуры рисовать?

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

Почему же потеть? Чем обработчик события OnDrawColumnCell сложнее скрипта в Power Builder?

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

Как я понимаю и сортировка и филтрация делается в кеше? А если надо это сделать на сервере? Есть такая возможность?

Ну почти все вопросы сравнили :)

Пару дополнений :

1. Раз любой контрол является наследуемым от предка внутри формы и весь код обработки событий вносится в его класс, то естественно код изчезает после его удаления из формы. Что это - недостаток или достоинство сказать сложно. С одной в Delphi из за того, что событие является делегатом, то бишь просто указателем на некую процедуру, можно однотипные события многих компонентов указать на одну единственную процедуру его обработки и центролизованно все обрабатывать. С другой стороны при удалении ненужного компонента весь код как мусор остается в форме Delphi. Еще аспект - в PB весь код обработки неких событий обьекта, имеющего родителем форму сосредоточен внутри его класса, в Delphi код событий пишется в виде процедур родительской формы. Как итог - без дизайнера в коде формы Delphi очень сложно сказать, какие процедура служит событием каких обьектов (во всяком случае без чтения DFM это вообще не реально). В PB это элементарно, раз уж весь код сосредотачивается в классе контролса. Еще кстати в PB 8 можно просмотреть и отредактировать весь код и описания свойств любого обьекта, формы, меню и т.д. как и в Delphi, для этого там предусмотрен спец. редактор.

2. Ваш пример использования ExecSQL опять же пример работы компонентно-ориентированных языков. Чтобы выполнить ваш пример нам как минимум придется создать, инициализировать и определить обьекты TDataSet и TParams. Параметры кстати еще определить и заполнить придется. В PB интеграция SQL с самим языком берет все на себя:

int value, id
id = 1

SELECT Value
INTO :value
FROM Table1
WHERE id = :id

3. Разница все таки насчет логики, разбросанной по контролсам или в одном месте для меня есть. В PB код получается центролизованней и читабельней засчет того, что вся работа с визуальным отображением данных сосредоточена в одном компоненте, с очень хорошими продуманными возможностями и событиями как для управления визуальными отображениями данных, так и самим состоянием набора данных. Опять же если коснуться DataWindow, то можно подчеркнуть, что во первых он изначально ориентирован на работу через кэшированные изменения (я например считаю на сегодняшний момент его реализацию кжшированных изменений наиболее удачной, по сравнению с BDE, JDBC или ADO.NET), причем с гибкими настройками, позволяющими настроить, как PB будет генерить запросы на изменение данных, пользоваться первичными ключами, поддерживать автоинкремент или же поддерживать запись измененных данных через ваши хранимые процедуры. Во вторых на многие важные свойства любого обьекта в DataWindow можно написать свой скрипт, определяющий значение этого свойства (сделано один в один, как в Crystal Report) - в любом гриде Delphi придется же попотеть, чтобы например в зависимости от условий устанавливать цвет и фонт колонки для каждой строки набора данных. В третьих DataWindow может выступать и гридом, и простой формой ввода в виде контролов, и отчетником (в том числе и кросстабом) и графиком (причем довольно навороченным). Выигрыш очевиден - один обьект DataWindow, с интегрированной кучей возможностей - не надо осваивать сторонние компоненты, каждый со своими принципами работы, а то и встроенными собственными скриптовыми языками. В четвертых - DataWindow держит в функционале все, что нужно в любом нормальном гриде, но почему то в стандартных гридах всех инструментов, провозглашенных, как средство разработки клиентов БД отсутствует. Это сортировка, фильтрация, вывод на печать, расширенный визуал (например возможность в одной строке грида располагать колонки в несколько рядов вертикально, автоматически расширять высоту строки грида в зависимости от высоты столбца и т.д.). Все это конечно реализовано в сторонних гридах в той или иной степени и с тем или иным кол-вом глюков.

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

5. В догонку к SQLPreview, встроенному в сам PB заодно можно вспомнить еще и конвейер данных, который может прямо встраиватся в приложение и ничем по функционалу не уступает DTS от MSSQL Server 7/2000. Опять же мелочь - а удобно.

6. Теперь последнее и главное. Насчет стандартного супнабора компонент и моего высказывания, что придется попотеть и делать. Наверное я опять просто неточно выразился, отсюда и недоразумения. С моей точки зрения весь код любого приложения делится на 2 части - это системная логика (набор компонент, код из стандартных библиотек, работа через WINAPI и т.д.) и бизнес-логика самого приложения. По моему разумению системная логика должна быть изначально достаточной и обеспечивать программиста всем необходимым функционалом, чтобы он мог без проблем реализовать с помощью нее необходимую бизнес-логику приложения. В итоге прозрачность доступа к источникам данных в PB - это пример достаточной системной логики, позволяющей мне даже не задумываться об этом, раз это есть и работает, а например собственные компоненты, наследованные от стандартных визуальных с целью добавления некоего функционала бизнес-логики под конкретную задачу или реализацию некоего часто повторяемого алгоритма во многих местах приложений, и являются тем самым практичным расширением функционала PB и собственных наработок. Так что море визуальных компонент под Delphi вряд ли говорит о том, что это решает проблемы эффективности разработки клиентских приложений под БД. Тем более, если учесть, что большая часть этого моря - это красивые панельки, кнопочки и всякий другой визуальный мусор, без которого можно спокойно прожить. Для написания же группы действительно мощных и нужных компонент нужна контора и проффесионалы, и то догнать промышленные разработки им будет чрезвычайно сложно, и все равно один только DataWindow из PB будет перекрывать одновременно по возможностям и кач-ву тот же DexExpress QGrid и FastReport вместе взятые. Это то же, как сравнивать любой отчетник под Delphi с Crystal Report - абсолютно бесполезный номер, так как разные весовые категории.

Ну а насчет когда чего то не хватает коварный вопрос - а что такого может не хватать при разработке клиента под базу данных ? Все что нужно для построения форм и отчетов есть, а для подключения специализированных решений в PB есть поддержка WINAPI, VBX, ActiveX, DLL, COM, Java и DotNET.

Ответ на »сообщение 58« (ASCRUS)
___________________________

Опять же - "делается". То есть тратится энное время на разработку и отладку. Гораздо приятней, когда это все есть в стандартном супнаборе :)

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

Определитесь Уважаемый. "есть в стандартном супнаборе" или все таки
"расширить где надо функционал стандартных контролсов и дописать свои". Заметьте, в последнем случае Вам никто не поможет. В отличие от Дельфи, где этих дополнительных контролов со стороны - море.

2 ASCRUS
Вы привели длинный перечень того, что Вам нравится в PB.
После чего заявили, что все перечисленнове Вами есть плюсы PB по сравнению с Дельфи.
Видимо Вы просто забыли, что среди перечисленных Вами достоинств PB, есть немало аналогичных в Дельфи. Что и привело к непониманию.

1. Насчет встроенного SQL - попробуйте через ExecSQL выполнить код, который вызывает ХП, передает и получает от нее параметры, тут же прогоняет по возвращаемому ее набору записей курсор и что то делает внутри цикла перебора записей (например заполняет собственный класс, попутно вызывая дополнительные ХП).
В чем проблема, уважаемый ?

lqry := ExecSQL('sp_AddItemsToInvoice',InputParams, ReturnValues);

в lqry Вам возвращается рекордсэт, а в ReturnValues - возвращаемые значения из ХП.

3. Насчет разброса логики по контролам и классам....
Простите, но я не понимаю принципиальной разницы между разбросом логики по событиям одного гигантского компонента (datawindow), и разбросом логики по событиям нескольких компонентов (dataset, grid)
При чем тут сложные формы ? В моем текущем проекте на Дельфи У меня на некоторых формах более 10 (!!!!) закладок с сотнями контролов, включая несколько гридов. Я делал аналогичной сложности формы на PB. На PB это было делать значительно сложнее (для меня).

Кстати насчет кода PB в событиях, хранящихся вместе с классом - вы батенька видно плохо PB знаете.
Спасибо за разьяснение механики работы PB, но Вы в лучших традициях Горбачева так и не ответили. Так пропадет код если я удалю компонент с формы или не пропадет ?

4. Насчет кучи компонент в Delphi выскажусь еще раз. Во первых в PB не надо сторонних компонент - там все есть сразу.
:))))) В этом коренное отличие между нами. Мне всегда чего то не хватает. PB - это закрытая система где "все есть сразу". Но не дай бог, Вам что то понадобится, чего нет в стандартном наборе. Вам остается только надеяться , что в следующей версии (!!!) это появится. Таким образом - достоинство - все есть сразу. Недостаток - Если чего нет - то это надолго. Пусть каждый сам решает, что ему важнее.

6. Насчет SQLPreview. Я пользуюсь Profiler от MSSQL и ODBC log.

Опять же - "делается". То есть тратится энное время на разработку и отладку. Гораздо приятней, когда это все есть в стандартном супнаборе :)

2. Насчет подключения к БД.
[...]
Но маленькое "но" - весь доступ к данным реализован естественно через компоненты (а как бы еще можно было в компонентоориентированной среде сделать), а это кстати накладывает естественное ограничение - посмотрел бы я на Ваши попытки готовую программу на Delphi, работающую через ADO заставить работать через компоненты DBExpress, OLEDB или компоненты нативного доступа.


Да кто ж в сколько-нибудь сложных приложениях напрямую работает с компонентами?? Делается интерфейс (фасад), скрывающий механизм доступа к БД.

Ответ на »сообщение 55« (ASCRUS)
___________________________
>>>Насчет SQLPreview - Вам никогда не хотелось увидеть в рунтайм код SQL-скрипта, который генерится для того же обновления записи самим компонентом доступа к данным ?
>>>Уже на этапе его сборки, когда все параметры в нем заполненны, осталось только на сервер отосласть ?

В частности, приходится использовать для этих целей Profiler от MSSQL, т.е. без дополнительных инструментов обходиться в этом случае не удается.

Jack Of Shadows:

Придется отвечать, раз уж меня обвинили в некомпетентности :) Чтобы не разгонять флейм, на обвинения отвечу кратко и первое, что хочу подчеркнуть - я не писал, что на Delphi чего то нельзя сделать. Я писал, что на PB это можно сделать легче. Большая заметьте разница между этими высказываниями. Теперь по пунктам:

1. Насчет встроенного SQL - попробуйте через ExecSQL выполнить код, который вызывает ХП, передает и получает от нее параметры, тут же прогоняет по возвращаемому ее набору записей курсор и что то делает внутри цикла перебора записей (например заполняет собственный класс, попутно вызывая дополнительные ХП).

2. Насчет подключения к БД. Да в Delphi появилось куча способов подключения к источникам данных. BDE, со старыми глюками и ограничениями, тянущихся с его первых версий, лучше не брать в счет. Через все остальное можно довольно удачно подключатся. Но маленькое "но" - весь доступ к данным реализован естественно через компоненты (а как бы еще можно было в компонентоориентированной среде сделать), а это кстати накладывает естественное ограничение - посмотрел бы я на Ваши попытки готовую программу на Delphi, работающую через ADO заставить работать через компоненты DBExpress, OLEDB или компоненты нативного доступа. С учетом того, что каждый способ доступа имеет свои правила, события и т.д., то компоненты и способы работы с каждом из них все равно в мелочах отличаются. Именно это Дмитрий и имел ввиду, подчеркивая прозрачность подключения в PB.

3. Насчет разброса логики по контролам и классам. Вы никогда не делали сложные формы редактирования, с вкладками, кучей гридов и контролов одновременно ? Так сказать для удобства интерфейса, чтобы юзер не открывал тысячу модальных окон и не плевался ? И кстати обычно правилом хорошего тона является кое какую часть логики ввода входящих данных реализовывать помимо сервера еще и на клменте, так сказать чтобы не напрягать лишний раз сервер, да и опять же для качества интерфейса - например гасить что не может вводится, проводить локальные проверки на правильность ввода данных м т.д. В PB DataWindow является одновременно набором данных и визуальным его отображением, так что код по всем этим проверкам будет довольно логичено расположен в самом нем. В Delphi все действия придется раскидывать по событиям как самого DataSet, так и контролсов.

Кстати насчет кода PB в событиях, хранящихся вместе с классом - вы батенька видно плохо PB знаете. В PB - событие - это аналог виртуального метода в Delphi (разве что принципы наследования малость другие), каждый обьект который ложится на форму PB наследуется прямо внутри формы от предка и любой ваш код в событии этого обьекта - это перекрытие метода предка (наглядный пример - в событии контрола Edit THIS будет равен не форме, а самому Edit). Чем то это смахивает на анонимные классы Java, но уж никак на события-делегаты Delphi или C#.

4. Насчет кучи компонент в Delphi выскажусь еще раз. Во первых в PB не надо сторонних компонент - там все есть сразу. Во вторых - чтобы сделать в runtime дизайнер пользовательских компонент, придется наверное еще и скрипт своего языка цеплять ? А потом поедет и помчится ? Такие наработки кстати уже в Delphi я видел. Тем интерпретатор и хорош, что он позволяет весь свой функционал переносить и использовать в runtime приложения. В этом плане, где выгоднее универсальность, а не скорость (что и нужно в клиентском приложении), он всегда будет по многим пунктам выигрывать у компилятора, а если вспомнить, что весь движок делал Watcom, то думаю PB в сильной медлительности по сравнению с тем же VB обвинить сложновато.

5. Насчет динамического подключения библиотек - я и не утверждал, что в Delphi всего этого нет и я этим не пользуюсь (типа написал кучу собственных компонент и никогда не слышал про BPL). Наоборот - я подчеркнул, что это есть и в PB, так как все это - важные моменты.
И еще -  reflection классов в Delphi не самый удобный момент в жизни программиста. В том же PB, Java или C# все гораздо удобнее и правильнее.

Кстати Вам на заметку - Reflection - это не смена в рунтайм свойств компонента, а исследование структуры библиотек и классов.

6. Насчет SQLPreview - Вам никогда не хотелось увидеть в рунтайм код SQL-скрипта, который генерится для того же обновления записи самим компонентом доступа к данным ? Уже на этапе его сборки, когда все параметры в нем заполненны, осталось только на сервер отосласть ? А может даже и поменять перед посылом к серверу ? (не спорю редкий случай, но все таки возможный). Или никогда не хотелось сделать трассировку в рунтайм всех SQL скриптов, посылаемых клиентом к серверу БД ? Иногда для отладки очень даже полезно, особенно при логировании ошибок, возникающих на клиенте. А насчет как посмотреть генерящийся препаренный SQL скрипт в TQuery или SQL Explorer да еще и в рунтайме - я Вас не очень понял, наверное Вы не то имели ввиду.

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

P.S. Уф - все равно длинное сообщение получилось :) Прошу извинения у всех, кого достало это читать :)

Ответ на »сообщение 53« (Сергей Тарасов)
___________________________
У кого что болит, тот о том и говорит.
Заметьте, что ни Акуличев Дмитрий, ни ASCRUS, ни слова не сказали о проверке sql на этапе компиляции. Зато Дмитрий ругался именно на форму записи, на что я и ответил примером почти аналогичной формы записи sql в Delphi. Мне кажется, пример, приведенный Дмитрием в пользу встроенного sql, красноречиво свидетельствует о характере "проблем", возникающих у Дмитрия и их причине.

Что касается проверки sql скриптов. Если sql зашит в код (а только в этом случае и будет осуществляться проверка в PB), то такого же уровня проверку предоставляет и Дельфи. Достаточно в designtime активировать TQuery с sql скриптом, как тут же получите сообщение об ошибке с указанием где она произошла. Заметьте - до компиляции.
Если же sql скрипт создается динамически то тут и в PB ни о какой проверке говорить не приходится.

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

Ответ на »сообщение 52« (Jack Of Shadows)
___________________________
Поповоду встреннного сиквела вы погорячились. Преимещество не в форме записи, которую можно и на дельфи максимально приблизить к таковой же на встроенном SQL, а в том, что корректность запроса проверяется еще на этапе компиляции.