Вас порвут, уважаемые :)
Lav
Королев
Помнится, давно уже вам говорили, что пора на .NET портировать продукт и использовать его преимущества, потому как M$ неотвратимо наступает... Про WYSIWYG сейчас не стоит - до релиза 2.0 как раз сделали бы. И что в итоге? Делфи, масса неудобств с постоянно меняющейся функциональностью (в том числе в скриптовом движке) и (теперь уже затихшие) мольбы разработчиков, в большистве своем вынужденно пересаживающихся на .NET. А теперь еще раз загляните к StimulSoft'овцам! В 1.3 доделан WYSIWYG, народ пачками переходит с Crystal и ActiveReports на Stimul.. А вы цены задираете 
Про аналогичные вашим примеры - это фигня. Вы хоть поняли, как построен StimulReport?! Предельно очевидная мысль в контексте .NET и блестяще реализована! Похожесть с FR зря вас расслабила - внутри ничего общего. Короче, люди! Если вы не возьмете руки в ноги и не зашевелитесь, то с ентим гадским дотнетом скоро пролетите, как стая рашпилей!
Про аналогичные вашим примеры - это фигня. Вы хоть поняли, как построен StimulReport?! Предельно очевидная мысль в контексте .NET и блестяще реализована! Похожесть с FR зря вас расслабила - внутри ничего общего. Короче, люди! Если вы не возьмете руки в ноги и не зашевелитесь, то с ентим гадским дотнетом скоро пролетите, как стая рашпилей!
Комментарии
>>Вы хоть поняли, как построен StimulReport?!
дайте исходники - посмотрим, и может быть, поймем...
Приниципы построения отчётов, действительно, несколько разные.
Думаю, Виталик Кубекин (stimulsoft) не обидится, если я его немного процитирую:
Так, что в данном случае на выбор сыграл психологический фактор, но повторяю это частный случай. FastReport был "народным" продуктом (по цене) и теперь тяжело поломать стереотип, что надо платить больше. Ситуация очень напоминает события с AMD - пока была гадким утёнком на всю трубила, что её интересует только конечный пользователь, поэтому и цены "народные", и что мы видим сейчас? Бизнес. Хочется надеятся, что Ваши маркетологи, Александр, на правильном пути.
>>Очень многие сидят на MSVC 6 и на net плевать хотели...
Вы давно работу меняли? Я не о факте смены работы, а о вакансиях на рынке труда для разработчиков ПО.
Рынок диктует приоритетные средства разработки, причем по объективным причинам (всем здесь, наверное, ясно чего и как быстро обычно хочет заказчик).
Можно только сказать - плюйте
>>Кстати, цены у них выше на $150. И где там 1.3? На сайте речь о 1.23.
Цены выше только на корпоративный вариант, но там уже совершенно другие вопросы. Касаемо 1.3 - если интересно, то к разработчикам. Скоро выложат.
ЗЫ
Не воспринимайте, как "наезд". Я не абсолютизирую Stimul. Я вообще с ним еще толком не работал. Я разобрался, чего они сделали, и могу в плюсы цитаты Виталия Кубекина дописать еще целую уйму топиков, которые любой может найти в хорошей книге по .NET. Все это, действительно, в большей мере касается разработки под .NET, но последняя, черт побери, наступает! Обращением к разработчикам FR я подчеркиваю небезразличие многих к их продукту и призываю вступать в конкурентную борьбу. Ведь нам всем это не помешает, верно?!
Выпуск FastReport.Studio напоминает советские времена, когда выпуск изделия планировался за 20 лет вперед и под него готовилась инфраструктура, поставщики, сбыт и т.п. Примеры: советский видеомагнитофон( 1970-е годы), или персональный компьютер ( 1980-е). К тому времени, как продукт запускался в серию, он морально устаревал и поставлялся только на те предприятия, которым был запланирован, и которые, используя данную технику, не могли выдерживать конкурентную борьбу (качество телепередач, скорость расчетов и т.п.) Я о том, что разработчики, используя данную технологию отчетов, со временем будут проигрывать тем, кто использует отчеты на нетовских движках. Предполагаю, что это время наступит при использовании новых операционок и SQL сервера с поддержкой .net, которые на подходе. К разработкам отчетов под Windows-приложения мое мнение не относится.
В качестве примера можно привести Кристал - он ненативный, однако интегрирован в среду разработки на порядок лучше, чем все "нативные" решения. В чем, по-вашему, преимущества нативных решений? В наличии исходников? В расширяемости? По скорости и функциональности они сейчас в достаточно сильном проигрыше.
Вместо множества скриптовых языков в отчетности с нетовским движком можно использовать .Net CLR. Поскольку сборки .Net являются заранее скомпилированными, то мы получим существенное увеличение производительности.
В Юконе вообще реализована интеграция .Net CLR и ядра SQL Server. Следовательно, в .net можно вынести всю математику, лексический и синтаксический разбор и т.п., т.е. все, для чего TSQL не предназначен
.. как бы не начать священную войну
и ваще, я люблю борланд!
Может быть раскритикуете здесь обёртку над нетовской DataTable, которая поставляется в демках? Было бы очень интересно послушать.
Однако, студия уже давно умеет выполнять С# код, посредством события OnUserFunction().
Вместе со студией поставляется пример UserFunctionExample, в котором число переводится в строку прописью. Таким образом, особо критичные места студия умеет выполнять в С#, впрочем, как и в C++ и в других языках/средах.
Для уточнения - я говорю только о проектах, исполняемых в .Net CLR.
Все это продожает говорить о том, что fr inc не уловила смысл ветки этого форума...
"...Очень многие сидят на MSVC 6 и на net плевать хотели... "
"...дайте исходники - посмотрим, и может быть, поймем..."
Это опять о том, что ни Александр, ни Михаил не уделили внимание названию ветки этого форума.
Почему:
1. пользователи FR говорят о fr.net очень давно, а компания только игнорирует эти разговоры?
2. сейчас, когда говорят напрямую "вас порвут", опять звучат слова о том, что есть другие рынки, которые интересны компании?
3. пользователи (в т.ч. бывшие) пытаются говорить о том, что за .net будущее (ближайшее), а у многих это уже реальность, а FR.NET нету?.. есть Студия... которая, как и fr3, многим кажется неадекватными затратами и вложениями fr inc
4. до сих пор в fr inc нет понимания .net (и многообразия источников данных в .net)
наша компания работает под .net ...
fr.net нам уже не интересен. мы уверены, что fr inc не сможет его сделать, если не изменит отношение к .net.
мы используем StimulReport более 6 месяцев. это несравниваемый с FR продукт. это другое. это как QR1 с FR3 сравнивать.
мы очень уважаем fr inc. именно поэтому пытамся тоже написать в этой ветке.
мы, как и многие из тех, кто написал в этой ветке, надеемся, что fr.net появится.
но, если это будет через пару лет и с таким отношением к .net - fr inc рискует быть "порваной" конкурентами.
А Вы посмотрите, сколько пользователей на этой ветке форума. Также загляните на соседние ветки.
И все же, я не услышал ответа, чем нативное .net решение лучше, чем win32 dll. Кстати, а чем вы в Stimul диаграммы строите?
Сравнение не .net решения vs win32, а Fast vs Stimul.
Минусы (навскидку):
1. Использование своих скриптовых языков. Я не спорю, реализация может быть чудесной, но необходимо время на изучение + практика. В своё время намучился с кристалом. Так как пользуюсь редко, каждый раз, как припечёт, приходится изобретать велосипед. Меня просто поразило решение использовать в Stimul в качестве скрипта полноценный .net, а главное насколько это удобно и упрощает жизнь! Плюс возможность использовать в проекте отчёт в виде Xml, dll или просто кода.
2. Как писал vlad_galaxy: “А как работать со сложным датасетом, имеющим несколько таблиц и DataRelations?”, то есть не полностью реализована работа с датасетом.
3. Мне не нравится использование в одном проекте разных технологий, таких как com и net. Как писал Michael: “В качестве примера можно привести Кристал - он ненативный, однако интегрирован в среду разработки на порядок лучше, чем все "нативные" решения”, но, кто сказал, что разработчики в восторге от кристала? Лично я был вынужден им пользоваться на vb6, не было альтернативы, такой как у Delphi FastReport, но я им сыт по горло. В общем я сторонник простоты - .net так .net, или com так com, легче жить как разработчикам так и сопровождающим.
Плюсы:
1. Ресурсы. Я немного поэкспериментировал: отчёт содержал около 50 TfrxMemoView (в Stimul - Текст), создавалось около 1 тысячи страниц (точно не помню). Fast справился ~ за минуту-полторы и “скушал” около 50 или 70 MB ОЗУ, Stimul ~ 4-5 минут и ~ 500 MB ОЗУ (по диспетчеру задач, но можно ли ему верить?).
2. Реализация построения диаграмм. Я ещё не спрашивал Виталия Кубекина, но думаю, что в Stimul это скоро появится.
Проанализировав ситуацию на рынке, можно прийти к следующему выводу: если считать .net более перспективной технологией, и, следовательно, более высокооплачиваемой, то плюс №1 отходит на второстепенный план, разработчики пишущие новые проекты на .net, по возможности будут подбирать и .net инструменты, да и наверняка многие заказчики будут предъявлять такие требования.
Ещё: вам нужно было реализовать поддержку ado Recordset VB6, он продолжает оставаться популярным языком, достаточно зайти на сайт Релиб.
Могу утверждать, что FastReport умеет работать .NET с объектом DataTable.
Мне кажется, что Вас ввел в заблуждение тот факт, что во всех демонстрационных отчётах используется встроенный ADO движок. На самом деле, в исходниках демок есть простейший пример, как сделать сделать DataTable прозрачной для FastReport.
Или Вы желаете чтобы все обёртки между COM и .NET были вынесены в отдельную strong name библиотеку и распртранялись вместе со Студией?
Если я неправильно понял, то, пожалуйста, объясните в чём я ошибаюсь.
В действительности - немного не так.
Обёртка, назвовём её для простоты FrxDataTable, наследована от DataTable, при этом сохраняет все возможности оригинального DataTable.NET.
Прозрачность DataTable по отношению к FastReport достигнута за счёт добавления свойства TfrxUserDataSet к DataTable и пары обработчиков событий. При этом, добавление столбцов в DataSet автоматически добавит столбцы в TfrxUserDataSet (.NET действительно рулит).
Выборка данных в отчёт берётся непосредственно из DataTable. В этом случае встроенные в FastReport движки баз данных не задействованы.
Хочу ещё раз обратить Ваше внимание - прозрачность DataTable по отношению к FastReport сохраняет доступными все свойства таблицы.
Таким образов DataSet.NET может включать в себя одну или несколько FrxDataSet без потери функциональности.
Я бы тоже так поступил, но сейчас нам приходится находить компромисс между
встраиваемыми решениями и standalone solutions.
Скорее всего, в будущем мы вынесем движки баз данных из ядра, но это дело времени.
Надеюсь, предыдущий пост хорошо объясняет принцип работы FastReport c DataSet.NET.
Пожалуй, это наиболее веский аргумент из всех вышеперчисленных.
Не будем спорить о простоте сопровождения
Что же касается простоты, то, по большому счёту, с точки зрения прикладного программиста, - и .net и СОМ объекты - всего лишь интерфейсы. Правильно?
Наша задача - сделать эти интерфейсы наиболее удобными и прозрачными для использования во всех средах разработки и языках программирования.
Могу утверждать, что FastReport умеет работать .NET с объектом DataTable.
..."
1. DataTable... (нет связей в fr studio)
2. Bussiness Objects
3. DataView
4. Enumerable Sources
5. xml datasources
5. доступ к данным (oledb, odbc и пр.) прям из генератора
(то, что всегда было интересным в fr2, fr3...)
"...>Почему:
А Вы посмотрите, сколько пользователей на этой ветке форума. Также загляните на соседние ветки.
И все же, я не услышал ответа, чем нативное .net решение лучше, чем win32 dll. Кстати, а чем вы в Stimul диаграммы строите?
..."
и это весь ответ? больше сказать нечего?
чартов до сих пор нет в SR, говорят, что работы ведутся по созданию собственных (уровня Dundas).
Вы правы, спорить не будем, Вы просили указать недостатки (на наш взгляд) - мы указываем.
Присоединяюсь к ovs2 и добавляю замечания
1. FrxCOM живет в однопоточной комнате, поэтому сложно сформировать отчет на сервере для публикации (сложность реализации устойчивой работы в 3х уровневой архитектуре превысила разумные пределы)
2. дизайнер не может быть встроен в контейнер (например, типа TabControl), который де-факто стал стандартом для Windows Forms приложений.
Возможно, из-за сложности в реализации этих пунктов, FR INC. и обращает внимание посетителей данного топика на количество пользователей в соседних ветках.
Предварительные Выводы (за пять с половиной месяцев ):
1.FastReport.Studio для .Net ограниченивается использованием в разовых заказных проектах для мелких заказчиков.
2. Для использования в больших проектах необходима отдельная группа разработчиков для интеграции FastReport.Studio с основным проектом. (Возможна неудача из-за замечания №2)
В данном аспекте FR.com ничем не хуже Crystal. Взгляните на разовые проекты с использованием Crystal.
>2. Для использования в больших проектах необходима отдельная группа разработчиков для интеграции FastReport.Studio с основным проектом. (Возможна неудача из-за замечания №2)
Дизайнер FR никогда (с самой первой версии FR) не мог быть встроен в какой-либо контейнер. Может, для Вас это важно, но тысячи наших пользователей так не считают.
да! очень интересный вопрос!
- кто является целевой аудиторией?
- кому может быть интересен этот продукт?
- кто готов создавать "отдел интеграции продуктов с FR Studio"?
- ...
- "кто Слабое звено"?
Сами удивляемся!
Ну тут уж вы загнули. Или где-то есть "отдел интеграции продуктов с RaveReports" или "отдел интеграции продуктов с CrystalReports"?
Какой-то "сферический конь в абсолютном вакууме" - обсуждение на пустом месте.
?
С другой стороны - радостно, что бета продукта уже вызывает такой резонанс. Наши пользователи уже ходят вокруг, оценивают возможности, устраивают бенчмаркинг, предлагают нововведения, советуют, активно используют и т.п. Т.е. со студией мы не промахнулись.
Видимо, было не совсем верным решением обсуждение студии в топиках .Net, поскольку диапазон использования FR Studio всё же несколько шире.