Умбалансед ПарантхезизКто-нибудь скажет, что это:
?

Попытка сделать visio из дизайнера, вы не поверите, как только над ним не извращались уже.
Один из примеров "заточки" программы под ключ. И если все подобные хотелки реализовывать, будет уже не отчетник.

DimaBrFastReportsТем не мение выделили его как основную фичу :)
Я пытаюсь найти чем FR5 отличаться от FR4. Раз вы поменяли major версию продукта, значит произошли какие-то ЗНАЧИТЕЛЬНЫЕ ИЗМЕНЕНИЯ ФУНКЦИОНАЛЬНОСТИ, остаётся вопрос какие ?

Многостраничное превью. Это не просто добавленные вкладки. В 4-ке Report не мог содержать более одного инстанса построенных страниц, в 5ке это все переделано. Можно строить и открывать в превью несколько построенных отчетов из одного TfrxRepot, так и из нескольких.

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

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

Наследование шаблонов, теперь может вызывать и использовать скрипт. Т.е. можно вынести базовые вещи в шаблон предка не только в виде компонентов отчета, но и в виде скрипта.

Есть внутренние изменения для последующего перехода на новую версию, с новой сериализацией. Т.е. все элементы коллекций можно сериализовать в XML c уникальным именованием , для последующего наследования этих элементов(проще говоря, коллекции вроде переменных тоже можно наследовать).

2D штихкоды, которые вам почему-то , так не нравятся, что вы не считаете их за весомый компонент.

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

Новые экспортв HTML4/HTML5 (div), DOCX, XLSX, PPTX, SVG. Улучшенные старые, матрица экспортов с кешированием картинок. PDF-A (с нативным движком разбора и внедрения шрифтов, без использования api, поддержка битовых масок в PDF).

Сохранение пользовательских данных внутрь шаблона(можно хоть датасет туда сериализовать).

Мультиселект в дизайнере, объекты можно перемещать группами прямо в дереве объектов(либо перетаскивая бенд, на бенд перемещать сразу все объекты с одного на другой). Тоже самое в дереве данных, можно выделять несколько полей, если еще выделить и датасет, то дизайнер создаст сразу бенд с выделенными полями.

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

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

Поддержка лазаруса.

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

Если ничего из этого вам не нужно, то обновляться конечно не стоит.

DimaBrКак много букофффф.....
У меня аналогичную реакцию взывают ваши сообщения, вы пишете одно и тоже уже не знаю в какой раз.
И основная суть одна, я не использую - значит никому не нужно.
Мы разве вас насильно принуждаем обновляться ?
Всем хочется сидеть 10 лет на одном продукте и чтобы он поддерживался и развивался, получая бесплатные обновления.
Долго такой продукт проживет ?

DimaBr*Расширена итеративность, можно по клику на объект передавать параметры и строить новый отчет в этом же предпросмотре.
--- прекрасно строились новые отчёты по клику и в FR4

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

DimaBr*Так же, новые события у объектов, теперь можно подсвечивать объекты при наведении мышки на них из скрипта , или прям в коде компонента.
--- Это сильно !!! 10 строчек кода для добавления одного события в TfrxDialogControl. Этим можно гордиться !

Что ?
Причем тут диалоги ?
Смотрите отчет Detail report page.
Могли вы это так же просто сделать в FR4 ? - конечно, нет.

DimaBr*2D штихкоды, которые вам почему-то , так не нравятся, что вы не считаете их за весомый компонент.
--- Очень весомый !!! Килограмм эдак на 100-150. Главный вопрос а кому они нужны ?

Аптеки, ЖКХ (квитанции оплаты), Сбербанк, qr код сейчас активно везде используется. Я не знаю в каком году вы живете, что он никому нужен.

DimaBr*Не буду говорить про всякие мелочи, вроде упрощения форматирования в мемо и заливок (хотя второе, если раньше использовался TfrxGradient, не такая и мелочь. Ибо обрабатывается в экспортах совсем иначе).
--- Градиент на ЧБ принтере смотрится великолепно ! А ведь 99,99% пользователей на нём и печатают

Вы не поверите !
Печатают: визитки , открытки, конверты, беджи, лейблы.

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

DimaBr*Новые экспортв HTML4/HTML5 (div), DOCX, XLSX, PPTX, SVG. Улучшенные старые, матрица экспортов с кешированием картинок. PDF-A (с нативным движком разбора и внедрения шрифтов, без использования api, поддержка битовых масок в PDF).
--- Новые экспорты - это допиливание версии, а не новая FR5, не говоря уже о "улучшении старых"

Так рассуждая, можно сказать что и D2012 это D7 с апдейтом. Да и применимо это тогда к большинству софта(возможно и к вашему).

DimaBr*Мультиселект в дизайнере, объекты можно перемещать группами прямо в дереве объектов(либо перетаскивая бенд, на бенд перемещать сразу все объекты с одного на другой). Тоже самое в дереве данных, можно выделять несколько полей, если еще выделить и датасет, то дизайнер создаст сразу бенд с выделенными полями.
--- Ctrl+A + MouseMove. Неужеле кто-то пользуется деревом ? Что там можно сделать, если на форме лежит пару сотен мемок ? Значит я беру мемку в дереве и тащу её на другой бэнд в том же дереве ? Это извращение !

Извращение это создавать не динамические отчеты из кода, потом при любой изменении править код.

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

DimaBr*Новые режимы выделения объектов, выделить все объекты такого же класса в отчете или на предке(для удобства редактирования св-в вроде Stretch, когда нужно поменять у всех объектов).
-- Вы занимаетесь какими-то чудодейственными манипуляциями, которые в реальной жизни никто не использует. Неужеле в Delphi есть такой функционал и его активнно используют программисты ?
Есть один нюанс, Дизайнером пользуются не только программисты. Он и не должен быть как IDE.

А еще много из описанного Действительно есть в IDE, но они наверно тоже не знают что делают. Ведь , некто этим не пользуется...
Из описанного вами стало понятно, что отчеты вы дизайните в коде.

ЛюбезныйFastReports,
хотелось бы задать такой вопрос. В Delphi-версии с FR4 я без проблем управляю режимом дуплекса принтера через свойства компонента отчета. Как с этим обстоит сейчас дело в FR5 под Lazarus, в Windows и в Linux? Есть ли там сейчас такой функционал?
Под Win работает так же. А вот в Linux дуплекс не проверяли, там печать идет через qt.
Поставим в задачу, протестировать доп функции печати под qt.

ma1tusА вот этот момент совсем неоднозначный. Отчеты, которые требуются юзерам, нередко ни разу не укладываются в зашаблоненый механизм вывода; для наших так было проще (да и вообще-то не всегда возможно - инстанции требуют) научиться писать код в ManualBuild, обрабатывая "прокинутые" объекты, нежели отказаться от соответствия "извращенным снизу вверх шаг вперед два назад" бумажным формам.
Так я этого и не отрицаю. Бывают разные формы и разный их вывод.
Но в большинстве своем стандартные ср-ва покрывают большую часть требований. Как это не печально, но конечные приложения всегда ориентируются на большинство. Диковинные "штучные" хотелки не в приоритете.

Как раз это я и пытаюсь донести, что есть стандартные ср-ва, которые использует большинство, а есть дополнительные. А в ответ "это фигня, потому, что мне это не нужно". Не серьезно это :)

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

ma1tus касается и неразвития FS, в т.ч...
Потому, что FS слишком узко направленный.
Выделять на него кучу ресурсов, и в итоге 3-4 пользователя купят обновление. С таким подходом и растратами ресурсов будет тяжело не просто "ни развиться", а не потонуть.

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

ma1tusFastReportsПотому, что FS слишком узко направленный.
Выделять на него кучу ресурсов, и в итоге 3-4 пользователя купят обновление. С таким подходом и растратами ресурсов будет тяжело не просто "ни развиться", а не потонуть.
Направленный настолько узко, насколько его разработчик его сужает.
Одновременно предлагая его как отдельный продукт (зачем тогда?), и зажимая его как "дополнение к FR".
Он был разделен еще во времена FR3 чтобы проверить спрос.
Сейчас оставлен и поддерживается в качестве добавления новых платформ и фикс багов, чтобы не оставлять тех немногих пользователей совсем без обновлений.

ma1tusПорой очень заманчиво описать прикладную логику на уровне "отчета" без излишней поддержки со стороны хост-приложения (всё в том же ключе, что отчет сам, "изнутри", может коннектиться к базе и получать данные, практически делая заявку на самостоятельность), и классы, да и интерфейсы, очень бы пригодились. Однако - облом-с..., бесполезные они...

Эти классы не будут иметь ничего общего с классам Delphi, т.е. использование таких классов даже с стандартными методами RTL уже отпадает. Получается, придется дублировать часть нужного функционала в скрипте. А это огромные скрипты, для обработки таких объемов придется менять еще и концепцию(напомню, что промежуточный код скрипта это xml, парсинг строк итд). Получим Slow Script который строит Slow Report.
Это как раз тот случай, когда от инструмента заточенного под определенный вид деятельности хотят все, и переложить на него большую часть логики приложения. Тут проще будет воспользоваться крупными интерпретаторами, которые под это заточены.

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

ma1tusну и как, по топику - спроса нет?
Нет, и добавление обрезанных классов ситуацию не изменит.
По скрипту больше было запросов на поддержку мобильных платформ, чем на такую реализацию классов(я помню всех 3х человек, которые это просили).

asviridenkovIMHO это елинственно верный путь. Отчет не должен зависеть ни от чего в приложении.
Хост - приложение только предоставляет сервисы для выбора данных и передает параметры.
А надобность отчетника тогда в чем, если писать всю логику в коде.
В таком случае можно из того же JS генерировать HTML, вот и будет вся логика вне приложения. Только в чем удобность ?
Шаблоны для того и созданы, чтобы разработать визуальную часть и легко ее изменить, а не копаться в 10 скриптах если нужно поменять позицию мемки.

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

JaDiFastReports,

А можно сделать ERP/CRM систему с редактором, но переложить лицензирование на самих пользователей? Типа, в приложении есть редактор, но пользователи сами должны приобрести на него лицензию, если захотят спать спокойно.

Можно, но только с заключением партнёрского договора. Пользователи сами приобретают лицензию у вас как нашего партнёра. И им удобно - никуда не надо бегать, всё у вас приобретается, в одной точке, так сказать, и вам - вы себе партнерский %% оставляете, и нам.
И заодно вы же, как наш партнёр, контролируете лицензионность использования, поскольку и сами в этом заинтересованы ;)