Еще полностью не разобрался со всем, но пока могу сказать, что тестовые примеры работают. На днях будем покупать, подключать в свой программный комплекс, вот там и посмотрим
Fast Report 3 - замечательная вещь. Проголосовал - Отлично, но есть несущественные недочёты. Например для меня разница между FR2 и FR3 в форматировании числа - во втором выводит после запятой только значащие цифры, что часто очень удобно, а в третьем столько сколько задано в формате, по аналогии с Excel, что иногда не очень удобно.
Например, число 1,25 если в формате указано три знака после запятой, будет отбражено:
FR2 1,25
FR3 1,250
Второй недостаток - если в FR2 в отчете встретится какая-нибудь ошибка (например деление на ноль), то он все таки будет построен. А FR3 - нет.
Третье неудобство. Если в FR2 я выберу StoreInDFM=false то, при закрытии шаблона отчёта, Delphi не реагирует на произведённые с ним изменения - кнопка SaveALL в Delphi остаётся недоступной, как в принципе и должно быть. А при закрытиии FR3 Delphi реагирует так, как будто какие-то изменения я всё же сделал, что немного сбивает с толку.
И в завершении вопрос. FR3 признан продуктом года в 2004. А в 2005 был этот конкурс?
Мне лично не нравятся 2 вещи, с проблемы я успел столкнуться:
- работа в отладчике (малофункционально)
- работа с DateTime через драйвер ASA (приходится вручную перегонять время в подходящую строчку)
Нашел еще ошибку:
Если, находясь в дизайнере отчетов, вызванном из среды программирования, нажать функциональные клавиши и скомпилировать приложение, то в приложении не будут функционировать элементы управления.
Мне лично не нравятся 2 вещи, с проблемы я успел столкнуться:
- работа в отладчике (малофункционально)
- работа с DateTime через драйвер ASA (приходится вручную перегонять время в подходящую строчку)
Да, кстати проблемы есть. Тоже с датами
1. Использую драйвер ADO. Кладу на диалог TDateEdit(или как он называется не помню). Создаю запрос, в параметрах создаю новый параметр указываю тип Date(заметьте! - не DateTime), указываю , что значение беру из этого Edit`а. Запускаю. Смотрю в профайлер - передается datetime формат с указанием даты и времени... Обхожу так Делаю Trunc(DateEdit1.Date), а затем вручную привожу к нужному формату.
2. При сохранении отчета с выбранной вкладкой диалоговой формы происходит переключение на вкладку отчета, а форма остается висеть... :-)
3. Насчет отладчика согласен, что малофункционально. Токовые брякпоинты бы. Да и событие OnException как обсуждали в ветке FastScript
Дамы и господа, а как вы относитесь к передачи данных из программы в отчет?
Я считаю есть некоторые недоработки в этом плане. Нарпример передача параметра TfrxQuery из управляющей программы в запрос. Да и сама работа с параметрами запросов не особо удобная.
А как насчет удобства доступа к компонентам отчета?
Дамы и господа, а как вы относитесь к передачи данных из программы в отчет?
Я считаю есть некоторые недоработки в этом плане. Нарпример передача параметра TfrxQuery из управляющей программы в запрос. Да и сама работа с параметрами запросов не особо удобная.
А как насчет удобства доступа к компонентам отчета?
Вопросы ты задал ИМНО слышком обще, не совсем понятно что тебе именно интересует ...
Касательно работы с параметрами запросов лично у меня особых притензий нет.
Хочешь используй диалог задания параметров, хочешь задавай параметры в скрипте через ParamByName.
FR3:
В TfrxQuery пишем запрос:
select * from MyTable
where ID = :sqlID
в редакторе параметров указываю тип Integer и значение переменной <frxID>
Теперь при запуске отчета из программы, в качестве параметра запроса будет передаваться необходимое значение.
Так что как видишь, все достаточно просто.
при запуске отчета из программы, в качестве параметра запроса будет передаваться необходимое значение
Согласен, не сложно.
Но на ряду с этим есть возможность обратиться напрямую к параметрам запроса из управляющей программы. Зачем выполнять лишние манипуляции?
Эта возможность очень криво работает.
К примеру, если будет необходимость динамически менять запросы из программы (нечто вроде универсального отчета), и список параметров будет меняться, тогда что?
А я бьюсь сейчас с проблемой - сохранение и восстановление веденных пользователем значений в контролы на DialogPage.
До prepare без проблем пишу значения свойств.
а после - не могу считать и сохранить в ini-файле измененные пользователем значения.
Модератор,
может подчистим и отправим эту тему в важные, чтобы каждый входящий мог проголосовать и посмотреть статистику, чтобы не приходилось поднимать ее на верх новыми сообщениями?
Интересно знать мнение народа пользующего данное ПО.
Хороший, добротный продукт. По сравнению со второй версией, FastReport 3.xx, безусловно, значительный шаг вперед. Но, как всегда, не обходится без "ложки дегтя".
Есть претензии к фильтру экспорта в Excel. Почему-то почти всегда числа экспортируются как текст. Неприятно, если в формате числа в отчете присутствуют разделители тысяч. С такими числами без некоторых телодвижений в Excel оперировать не получается.
На мой взгляд, напрасно при разработке третьей версии исключили некоторый полезный функционал, так сказать, сделали даунгрейд (RoundRectObject, например, очень удобный был).
Есть претензии к фильтру экспорта в Excel. Почему-то почти всегда числа экспортируются как текст. Неприятно, если в формате числа в отчете присутствуют разделители тысяч. С такими числами без некоторых телодвижений в Excel оперировать не получается.
Хочу отметить, что в текущей стабильной версии этот недостаток устранен. Разделители тысяч уже не мешают. Теряется заливка ячеек.
...сама работа с параметрами запросов не особо удобная.
Есть такая фишка. Если один и тот же параметр в тексте запроса встречается несколько раз, столько же раз он присутствует в списке параметров. Если параметр участвует в выражении, например
:nyear*12+:nmon
,
то в списке параметров появляется все выражение. Бред. Приходится вставлять лишние пробелы.
Всем, наверное, известная "фича" FR: задание переменным отчета строкового значения.
При передачи строки в переменную отчета приходится добавлять дополнительные ковычки.
Я понимаю, что интерпритатор так работает, но это не выход!
Комментарии
Например, число 1,25 если в формате указано три знака после запятой, будет отбражено:
FR2 1,25
FR3 1,250
Второй недостаток - если в FR2 в отчете встретится какая-нибудь ошибка (например деление на ноль), то он все таки будет построен. А FR3 - нет.
Третье неудобство. Если в FR2 я выберу StoreInDFM=false то, при закрытии шаблона отчёта, Delphi не реагирует на произведённые с ним изменения - кнопка SaveALL в Delphi остаётся недоступной, как в принципе и должно быть. А при закрытиии FR3 Delphi реагирует так, как будто какие-то изменения я всё же сделал, что немного сбивает с толку.
И в завершении вопрос. FR3 признан продуктом года в 2004. А в 2005 был этот конкурс?
- работа в отладчике (малофункционально)
- работа с DateTime через драйвер ASA (приходится вручную перегонять время в подходящую строчку)
Если, находясь в дизайнере отчетов, вызванном из среды программирования, нажать функциональные клавиши и скомпилировать приложение, то в приложении не будут функционировать элементы управления.
1. Использую драйвер ADO. Кладу на диалог TDateEdit(или как он называется не помню). Создаю запрос, в параметрах создаю новый параметр указываю тип Date(заметьте! - не DateTime), указываю , что значение беру из этого Edit`а. Запускаю. Смотрю в профайлер - передается datetime формат с указанием даты и времени... Обхожу так Делаю Trunc(DateEdit1.Date), а затем вручную привожу к нужному формату.
2. При сохранении отчета с выбранной вкладкой диалоговой формы происходит переключение на вкладку отчета, а форма остается висеть... :-)
3. Насчет отладчика согласен, что малофункционально. Токовые брякпоинты бы. Да и событие OnException как обсуждали в ветке FastScript
Еще глюки вспомню, напишу.
Я считаю есть некоторые недоработки в этом плане. Нарпример передача параметра TfrxQuery из управляющей программы в запрос. Да и сама работа с параметрами запросов не особо удобная.
А как насчет удобства доступа к компонентам отчета?
Касательно работы с параметрами запросов лично у меня особых притензий нет.
Хочешь используй диалог задания параметров, хочешь задавай параметры в скрипте через ParamByName.
Вот пример :
Delphi:
frxReport.LoadFromFile('test.fr3');
frxReport.Variables := delphiID;
frxReport.ShowReport;
FR3:
В TfrxQuery пишем запрос:
select * from MyTable
where ID = :sqlID
в редакторе параметров указываю тип Integer и значение переменной <frxID>
Теперь при запуске отчета из программы, в качестве параметра запроса будет передаваться необходимое значение.
Так что как видишь, все достаточно просто.
Но на ряду с этим есть возможность обратиться напрямую к параметрам запроса из управляющей программы. Зачем выполнять лишние манипуляции?
Эта возможность очень криво работает.
К примеру, если будет необходимость динамически менять запросы из программы (нечто вроде универсального отчета), и список параметров будет меняться, тогда что?
?
До prepare без проблем пишу значения свойств.
а после - не могу считать и сохранить в ini-файле измененные пользователем значения.
может подчистим и отправим эту тему в важные, чтобы каждый входящий мог проголосовать и посмотреть статистику, чтобы не приходилось поднимать ее на верх новыми сообщениями?
Есть претензии к фильтру экспорта в Excel. Почему-то почти всегда числа экспортируются как текст. Неприятно, если в формате числа в отчете присутствуют разделители тысяч. С такими числами без некоторых телодвижений в Excel оперировать не получается.
На мой взгляд, напрасно при разработке третьей версии исключили некоторый полезный функционал, так сказать, сделали даунгрейд (RoundRectObject, например, очень удобный был).
то в списке параметров появляется все выражение. Бред. Приходится вставлять лишние пробелы.
При передачи строки в переменную отчета приходится добавлять дополнительные ковычки.
Я понимаю, что интерпритатор так работает, но это не выход!