Fastreport 5
Вопросы разработчикам:
Когда нас ждет FastReport 5?
Какие новшества в нём предполагаются?
Правда ли что в FR5 будут встроенные двухмерные штрих-коды?
Спасибо!
Когда нас ждет FastReport 5?
Какие новшества в нём предполагаются?
Правда ли что в FR5 будут встроенные двухмерные штрих-коды?
Спасибо!
Комментарии
Бета должна появиться в конце лета текущего года, либо в начале осени.
Релиз соответственно планируется на середину-конец осени(будет зависеть от результатов тестирования беты).
Много нововведений будет из .NET версии.
- объединение дубликатов;
- вывод простых иерархий;
- добавится несколько новых агрегатных функций;
- уберется inline форматирование в мемках(будет в виде коллекции);
- водяные знаки;
- улучшенные штрих коды (code128 -autoencoding, спец. символы (FNC), AI и тд.);
- двумерные штрих коды PDF417, DataMatrix;
- многостраничный предпросмотр для отображения детальных отчетов;
- детальные отчеты (как в .NET версии);
- улучшенная интерактивность объектов, события mouseEnter и mouseLeave, интерактивный чарт - возможно подсветки кусков серии и onClick события для них же;
- улучшенный кросс таб;
- некоторые новые объекты: CelluralText, ZipCode;
- возможно аналог таблицы из .NET версии заменит вертикальные бенды;
- Ribonn интерфейс;
- кэширование матрицы экспорта в файл;
- BIFF8 экспорт;
- XLSX, PPTX экспорты;
Это только малая часть роадмапа, будет много изменений, как и в функционале, так и во внешнем виде (дизайнер).
В общем если Вас интересует что-то конкретное или есть предложения, пишите.
апгрейд с 4.x - за доп. плату?
Единственный неопределенный момент сейчас это вертикальные бэнды, если они будут заменены таблицей, то возможно будет возможность подключать старый движок для обработки вертикальных бэндов.
Но этот момент еще не решен.
Ценовая политика еще не обсуждалась но, скорее всего, будет так же как и с апгрейдом 3.X на 4.X.
Если да, то так ?
2) Что по поводу изменений в FS ?
Поддержка записей, создание простейших классов (хотя бы коллекций и TPersistent) без наследования, более полная поддержка обработчиков ошибок, более полная поддержка EnumericSet (хотя бы на уровне Delphi7) ...
3) > уберется inline форматирование в мемках(будет в виде коллекции)
Не понял, это про что ?
4) > аналог таблицы из .NET
Это было бы очень желательно.
5) Для некоторых агрегатных функций (например для count) было бы неплохо добавить возможность работать только с уникальными значениями (аналог distinct в SQL)
6) Для печати колонок в DataBand'е - научить его печатать колонки не только слева-направо, но и сверху-вниз (как для страницы).
6) > BIFF8 экспорт
Было бы хорошо, что бы класс который создает xls (BIFF8) был доступен не только самому FR, но и внешнему разрабочику для своих нужд, то есть что бы можно было самому (при необходимости) писать и читать xls-Файлы.
7) Для внутренних источников данных добавить поддержку обработчиков полей типа OnGetText.
8) Добавить поддержку событий в OI при редактировании коллекций в FR IDE.
8.1) Для тех же коллекций, надо что бы FR научился сохранять для их элементов сложные свойства, например TBitmap.
9) Сейчас класс TfrxPictureView наследуется напрямую от TfrxView и из за этого, если я создаю свой класс для печати картинок, то FR не знает, что это именно картинки, из за чего оно не очень хорошо экспортируется.
Предложение: Надо создать общий класс для картинок, тогда от него можно будет наследовать и свои классы для картинок.
А остальное можешь посмотреть в моих письмах, если потерял их - могу выслать их еще раз.
Потом опишу более подробно.
С записями все плохо, т.е. можно сделать структуры в FS, но ничего общего с делфийскими структурами они иметь не будут.
А смысл тогда делать, все равно структуру FS не передать в функцию Delphi напрямую.
Классы без наследования можно конечно сделать, но зачем ?
наследования нет, опять же с Delphi классами ничего общего не будет.
[Customers."Addr1" #n%2,2m]
Вместо этого будет отдельное св-во коллекция и форматы для всех выражений можно будет устанавливать через редактор.
distinct как раз будет в ходить в новые агрегаты.
У такой печати есть свои особенности, но все возможно.
Так и будет.
Помню.
А разве сейчас не сохраняются ?
Все published пишутся автоматом, класс TBitmap не исключение.
Остальное придется писать через DefineProperties.
Сделаем.
- Что бы работало преобразование из числа в тип и обратно (новшество Delphi7), а что бы такие EnumericSet нормально понимались в FS, а то сейчас эта нумерация всегда идет с нуля, даже если тип описан как MyType= (m1=1, m2=2).
- Вспомни нашу переписку по поводу функции MessageDlg и ее параметров DlgType и Buttons.
Такие структуры конечно не нужны. Нужна поддержка структур, что бы иможно было передавать между Delphi и FS в обе стороны.
Есть потребность. В некоторых отчетах есть сложные внутренние расчеты с промежуточным хранением данных.
Для таких отчетов сейчас приходится использовать либо динамические массивы в FR (что не удобно), либо подключать к FR внешние классы коллекций (что влияет на автономность отчета).
Было бы гораздо удобнее, что бы такой класс можно было бы создать прямо в FR в скрипте.
Не понял. Создание, удаление, работа c классом будет как в Delphi ?
Или это имеется ввиду, что класс созданный в FS нельзя будет передать в Delphi ?
Если только последнее, то это конечно минус, но небольшой с которым вполне можно мириться.
Будет ли возможность указывать это форматирование динамически, из скрипта ?
Сейчас с этим есть определенные сложности из за которых приходиться для таких случаев использовать функции Format и FormatDate.
Если под особенностями понимается "двойной проход" и без этого никак, то путь будет - это лучше чем ничего.
Сейчас не сохраняется, эта беда тянется еще с FR3.
Если свойство TBitmap (или любое другое сложное свойство), у основного класса, то все сохраняется и читается нормально.
Но если такое свойство у коллекции, которую сохраняем/читаем посредством DefineProperties (frxWriteCollection и frxReadCollection), то такая коллекция больше не читается (что то там портится). Подробнее можешь спросить у TZ или я могу тебе переслать эту переписку.
10) Добавить в GroupHeader опцию, которая бы задавала его печатать перед Header (т.е. перед заголовком DataBand'ов)
11) Предложение по DataBand - свойство KeepGroupHeader
Добавить DataBand'у свойство "Держать заголовок группы". Очень надо для
отчетов с группами.
Свойство "держать" у GroupHeader не годится, так как оно пытается втиснуть
всю группу на остаток страницы и если не получается, то печатает группу с
новой страницы.
А мне надо что бы заголовок группы всегда печатался с данными, пусть даже
там только одна строка данных текущей группы. В общем аналог
"держать заголовок", но только для заголовка группы.
12) Есть простой отчет Master-Detail
Title
MasterHeader (ReprintOnNewPage)
MasterData (Stretched, KeepHeader)
DetailHeader (ReprintOnNewPage)
DetailData (Stretched, KeepHeader)
Кол-во строк у разных Master может быть разное, у одних Master например 5 строк Detail, у других Master может быть и 100 строк Detail, у третих Master может вообще не быть строк Detail и тогда печатется только Master
И в результате при печати такого отчета получается неправильная печать MasterHeader.
На 1-ой странице идет несколько мастеров и их детайлов. В конце 1-ой
страницы печатается очередной мастер и часть его детайлов, а остальные его
детайлы печатаются на 2-ой странице. И вся беда в том, что в начале 2-ой
страницы перед DetailHeader зачем то напечатался MasterHeader, хотя
и сразу после него и вообще на этой странице нет ни одной мастер-записи.
В принципе мы этот момент долго обсуждали в письмах "FR 4.7.11: Печать простого Master-Detail отчета" и вроде бы сошлись на том, что раньше 5.0 это не сделаешь. Вот хочу напомнить по этому поводу.
P.S.
Стоит ли мне сюда (в эту тему) перекидывать остальные предложения по FR5, которые я писал в письмах или нет ?
Такой класс нельзя будет передать, по сути это будет просто класс со списком методов, аналог TfsClassVariable , которые будут ссылаться на функции скрипта.
К примеру массив таких объектов фактически будет хранить экземпляры этого класс (TfsClassVariable), с коллекциями будет вообще все плохо.
Т.е. придется еще и писать специальный класс коллекций, чтобы можно было их использовать для такого объекта. А для реализации полноценного класса Delphi, придется дублировать все структуры vmt и заполнять и работать с ними вручную – это нереально.
Да.
frxWriteCollection и frxReadCollection должны писать все св-ва коллекции, что-то мне кажется мы о разных вещах говорим.
Можешь переслать переписку или номер тикета (если это тикет)?
Сделаем.
Про хидеры я помню.
Можешь просто напомнить мне номера тикетов, дублировать сюда смысла нет .
Конечно, если бы класс созданный в FS работал в обе стороны, это было бы неплохо, но если с этим есть большие трудности, то этого делать не надо.
Если мне нужен будет класс для работы в обе стороны, тогда я создам его в Delphi и передам в FS (так как это делается сейчас).
Это не тикет, а переписка с Александром (время Январь 2007, FR 4.0.18). Я часть этой переписки прикреплю к этому ответу. На последнее письмо (по поводу улучшения работы XMLSerializer), он кстати говоря так и не ответил.
В FR5 PropData по прежнему будут писаться в бинарном формате или в обычном текстовом (как остальные свойства отчета) ? Лучше, что бы как обычный текст.
Это хорошо.
Про эту проблему, было довольно длинное обсуждение в тикете TID#169276.
8) Не забудь добавить поддержку событий в OI при редактировании коллекций в FR IDE (я имею ввиду редактор типа frxChartEditor). Переписку по этому поводу можешь взять у Александра (письма с темой "Как добавить событие для работы в OI ?") или я могу тебя сам кинуть мылом эту переписку. Там кстати говоря вылезла с этим проблема в TfrxEventProperty.Edit (ограничение ядра FR4)
13) Думаю стоит добавить штатную поддержку PopupMenu для контролов диалога.
14) TID#176552. По этому тикету исправлен только п. 2, остальных исправлений и предложение не реализованы.
14.1) TID#175002. Тикет тоже про подсказки, но для контролов диалога.
15) Очень важный тикет TID#175204 с рядом предложений, в том числе и по работе с кодом.
16) TID#176310. По этому тикету до конца решение проблемы с обработчиком OnEndDoc не было найдено.
17) TID#175985, но лучше конечно сделать полноценную работу с exception, т.е. что бы работала конструкция вида
try
except
on E :КлассОшибки do
ShowMessage(E.Message)
end;
18) Важный тикет TID#171932 по работе механизма Master-Detail
19) Есть банд, на банде есть мемо, у банда и (или) у мемо прописан обработчик OnBeforePrint,
банд и мемо растягиваемые, но не разрываемые.
В общем случае этот обработчик работает нормально. Но если момент его вызова происходит в конце страницы, когда FR решает где печатать очередную строку банда (на текущей странице или перенести на следующую) то может получиться следующая вещь:
OnBeforePrint для текущей строки сработает на странице X, а фактически эта строка напечатается на странице X+1.
Соответственно хочется, что бы этот обработчик срабатывал только на странице, где реально будет напечатана строка или завести новый обработчик (OnBeforeExPrint) с такой особенностью.
Это весьма важно, для отчетов где печатаются данные в виде сложных форм (например регистрационная карточка Канцелярии).
Возможно частично эта проблема пересекается с тикетами TID#133106 и TID#143173
20) Не знаю, насколько это возможно, но было бы очень неплохо, что бы к HTML-tag добавить поддержку фона букв, их размера и шрифта. Использовать RichEdit для этого во многих случаях не удобно.
21) Добавить в словарь данных для переменных что то вроде обработчика OnGetText для полей, т.е. что бы переменной можно было задать значение не только в виде простого выражения, но и в виде небольшого куска кода.
21) Весьма важный тикет TID#156093 по работе с агрегатами в отчете, где куча колонок создается динамически из кода скрипта. В том отчете мне пришлось вообще отказаться от агрегатов и все считать самому.
21.1) TID#155552. Про автоширину листа в очень широком отчете с кучей колонок создающихся динамически из кода скрипта - пришлось считать и устанавливать ширину листа самому.
22) Попробовал воспользоваться компонентом frxCheckBoxView. Но обнаружил одну проблему: Он не умеет растягиваться - нет свойства StretchMode. Соответственно из за этого портится таблица.
Надо добавить ему это свойство и заодно свойства HAlign и VAlign что бы можно было удобно размещать пометку.
23) У компонентов FR4 (для диалога или печати) могут быть редакторы свойств.
Сейчас код этих редакторов свойств попадает в exe. Что бы этого избежать в FR4 есть специальный $define у NO_EDITORS, но работает он только во время компиляции программы (т.е. исходники FR + исходники компонент) должны быть доступны компилятору во время компиляции программы - а это не всегда удобно и возможно.
Было бы желательно изменить механизм подключения редакторов свойств для компонент FR, что бы убирание из .exe кода редакторов свойств регулировалось не через $define.
30)
TID#180249, TID#176309, TID#176064, TID#169279, TID#159602, TID#157738, TID#157275, TID#141768, TID#141768
TID#167612 (пункт 2), TID#157122 (по SyntaxMemo), TID#156124 (обращение из frxMemo.Text к свойствам этого frxMemo), TID#150808, TID#145978 (ошибка вроде бы исправлена, а предложение нет), TIз#133543 (пункт 1 и 2)б TID#133105 (эта проблема так и не была решена).
Часть из этих тикетов именно предложения. Часть нерешенные в FR4 по тем или иным причинам проблемы (не было ответа или ограничение ядра FR4) - соответственно предложение по ним решить эти моменты в FR5.
P.S. Чувствую, что после выхода FR5, уже не FR будет равняться на FR.NET, а FR.NET будет равняться на FR5
а если он мне не нужен?
Старые проекты переписывать никто не будет...
По поводу простейшей реализации классов еще подумаю.
По поводу записи коллекций, они же пишутся.
TBitmap серриализуется как простой объект, проблема при считывании.
Коллекции теперь будут записываться в XML, сериализер частично переделан.
PropData и будет и нет, автоматизировать уход от него не получится, если только не парсить делфийский стрим, но этот вариант не подходит из за производительности.
Запись не published св-в будет перекладываться на разработчика компонента, т.е. будет аналог TReader/TWriter и DefineProperties.
Если же компонент ничего не пишет по средствам нового метода, будет использоваться старый с PropData.
Фактически если правильно писать свои frx компоненты, PropData не будет.
Перешли мне переписку по поводу "Как добавить событие для работы в OI ?" на почту.
По тикетам обязательно пробегусь.
Konst,
Если не нужен, не используйте
Классический интерфейс никуда не денется, просто будет возможность выбора.
Примерно ясно, ну а конкретнее это надо самому смотреть и щупать как оно выглядит в коде и в fr3 файле.
У меня нет твоего e-mail. Или кинь мне его в личные сообщения (можно мылом) или тебе отправлять эту переписку на support ?
А то при экспорте получается казус на машинах с разными региональными установками. Встречалась даже ситуация, при которой например вместо 100 руб 0 коп (100,00) - Excel понимал как 10 000 руб. (Кстати этот вопрос поднимался на форуме и решение проблемы так и не последовало)
Есть ли возможность задать формат в зависимости от знака, как в Excel где можно 0 и отрицательные числа отображать как "-".
И в добавление, с точки зрения разработки. Я когда добавила в класс TfrxFormat ещё одно значение fkDateTimeLocale (о том, что говорилось выше), то его обработку пришлось вписывать в функцию function TfrxCustomMemoView.FormatData(const Value: Variant; AFormat: TfrxFormat = nil): WideString; блоком Форматов со временем может быть больше, и дописывая новый приходится влазить в базовый класс, что не есть гуд. Может обработку формата передать соответственно классу TfrxFormat, например метод Format (Value) будет возвращать результат в соответствии с установленным форматом. Тогда можно будет делать наследование класса TfrxFormat и не лезть в базовые.
1) Добавить поддержку листов Excel - это весьма актуально для отчетов в которых более 64000 строк.
2) Добавить поддержку стандартных формул (например sum, count, avg) - для экспорта простых таблиц с итогами, это было бы весьма полезно.
Никакой критики не выдерживает.
1) Добавить поддержку листов Excel с возомжностью выгрузки конкретных страниц в заданный лист.
2) Добавить поддержку Excel формул - если это реализуемо, это была самая необходимая возможность.
Кстати может стоит перейти на GZip 1.2.4?
http://fast-report.com/ru/forum/index.php?showtopic=6326