We realized it's time to start from scratch.
Why did you decide to build FlexReport?
ERIC: Our C1Report reporting solution started back in our ActiveX days, and when we moved it to .NET, we kept its architecture intact as ActiveX. It helped us push the product to the market faster and develop some followers right away. Over the past few years, there have been a lot of changes in reporting tools and customer expectations. We realized it's time to start from scratch, and develop new reporting tool that's faster, more efficient, and can help the developers (and their customers) better.
DMITRY: Technically speaking, an inadequate layout algorithm made it impossible to provide some commonly used layout features, like paginating two side-by-side sub-reports, which resulted in long-standing bugs impossible to fix.
ERIC: So we designed a new architecture around the new use cases—the world has changed a lot in 15 years—and made sure to stay true to the fundamentals of GrapeCity tools. Keep it flexible, keep it fast, and keep its footprint small.
Stay true to the fundamentals of GrapeCity tools. Keep it flexible, keep it fast, and keep its footprint small.
What were the primary goals with the new architecture?
SHILPA: Our main goal was performance. We wanted to render reports in half the time of C1Report. Our first baseline was a 200% improvement and we’re gauging success from there.
We also wanted to enhance the user’s design experience. A rich UI will take care of the learnability aspect, and it makes it so easy to use a tool. C1Report lacked that, and our goal was to revamp the UI so anyone can use it like Word or PowerPoint.
DMITRY: And we wanted to provide a cross-platform solution, which meant we had to remove the reliance on WinForms/GDI+. Instead, the new engine's rendering is based on DirectX/DirectWrite, and should be relatively easy to port to XAML/UWP platforms. And it’s faster, and renders better. It’s a good solution all around.
Which of the new features are your favorites?
SHILPA: The FlexReport Designer has a lot of new features that makes everything a lot easier. For instance, ParagraphField allows you to combine any number of expressions, text, fields, scripts, etc., into a single field, formatted any way you like. It’s like a rich text field for dynamic data. And if you want to develop a report similar to Mail Merge in Microsoft Word, you can do that easily in FlexReport, too.
The Data tab gives quick access to frequently-used needs like sorting, calculated fields, adding data sources, that kind of thing. Parameters are much easier to add and edit. And you can add fields and design the report itself easily, with snaplines, captions, sections, and it’s all in a designer so you don’t have to code any of it.
Frequently-used features are all in the Designer, so you don't have to code any of it.
Apart from the FlexReport Designer, we’ve really improved our Crystal Report migration, and I think that will also help with migrating other tools, as well.
ERIC: Our scripting is very cool, too. And it supports IntelliSense.
How has the architecture changed?
ERIC: We’ve always used our own internal format with reporting solutions, but we never standardized it. So this was our opportunity to define a standard document format for ourselves. Developers probably won’t even notice that change, but it’s given us a lot of flexibility and opportunities to go in new directions. For instance, we can view SSRS reports in FlexViewer, and in the future, we’ll be able to show even more different document types.
How is FlexReport different from out-of-the-box reporting in Visual Studio?
DMITRY: Crystal Report was bundled with Visual Studio for a very long time, and basically laid the groundwork for how developers visualize reports. Since Crystal Reports came out of Visual Studio, some of those fundamental concepts aren’t available any more. Developers don’t see the new features, like reporting services and PrintDocument, the way they’re used to seeing section-based reports.
We built FlexReport to support the expected user experience: design it in a WYSIWIG, embed in an application, and display in a viewer. We support common use cases, and we want to keep our footprint small, and our rendering fast.
(Editor's Note: You can see a full comparison of FlexViewer vs. Microsoft Report Viewer in Viewing SSRS Reports with FlexViewer.)
Why would a user want to use FlexReport instead of more expanded solution like SSRS or ActiveReports?
ERIC: Let me put it this way: each developer who needs to integrate reporting solution to her app consider lots of factors, like must-have features, use cases the product should have, deployment scenarios, cost and licensing of the product, cost of maintaining the solution within the app, ease of use, etc.
In the end, it boils down to multiple factors. For example, if the developer is looking for hosted reporting server, he’ll look for reporting solutions that can be hosted. If the user has the license of SQL Server/SSRS, then he may opt for SSRS, as there’s no additional cost. But if the report viewer needs to be customized to look different, then the user may look at some other tool.
FlexReport is targeted to those people who are looking for standard reporting scenarios and care about performance and small footprint.
FlexReport is targeted to those people who are looking for standard reporting scenarios and care about performance and small footprint. Since FlexReport is part of Studio, where you get grid and data management as well as data visualization tools, and other UI components, too, it’s cost effective.
What do you think developers will like the most about FlexReport?
SHILPA: I think they’ll love the performance, sharp rendering, and feature simplification. It’s really easy to build reports in the Designer.
ERIC: Developers who will be using FlexReport for first time will find this high-performing reporting solution, with a comprehensive set of features out-of-the-box, so I think they’ll love it, too.
It’s simply a set of 100% pure .NET components and visual controls.
DMITRY: I think the thing they’ll love the most is that it’s simply a set of 100% pure .NET components and visual controls. No hidden ActiveX controls, no servers or services to install—so development and deployment are straightforward and easy.
Will users be able to migrate from C1Report to FlexReport?
SHILPA: In the FlexReport Designer, just open a C1Report XML file and you’re done. The file will convert to FLXR and can be saved in that extension. In code behind, C1Report.xml can be directly loaded into a FlexReport class.
DMITRY: The overall object model of FlexReport is very similar to C1Report's, so most simple code working against it should just work. So they’ll need to update references and change the namespaces and component type names, like C1Report becomes FlexReport.
While there are new entities in the object model, such as SubSections, in most cases they should work transparently unless you need them. For example, a section always contains at least one sub-section, and fields in it can be accessed directly via the section.
One of the biggest differences is the field hierarchy. The old Field class is fully implemented, but now it’s derived from FieldBase, and the Fields collections on report and sections are collections of FieldBase rather than Field type objects. And FieldBase does not define all of the Field's properties. For example, text-related properties (Text, Font, ForeColor) are defined on the (legacy) Field type, and on the new TextField type.
How much time will it take to migrate?
DMITRY: Simply converting a C1Report report definition stored in a .xml file into a FlexReport .flxr report definition should be instantaneous. That includes VBScript event handling and standard custom fields (chart, QRCode, Gradient).
If an application has a lot of C# or VB.NET code that is written against the C1Report object model, there will be time needed to change the project references, namespaces, and component names. The time to verify the program logic should be small unless some hidden or undocumented features of C1Report were used. For example, in C1Report, when accessing a collection, elements of many collections were created on the fly. This is no longer the case, and can affect some non-trivial code.
The visual controls are very different, so any code that extensively manipulated the C1Report visual controls (like C1PrintPreviewControl) will have to be rewritten against the new FlexViewer control's object model. But code written against visual controls is usually pretty straightforward, so this should be less of a problem.
SHILPA: The good news is, once you migrate, features like Parameters, Sorting and CalculatedFields require so much less effort that you’ll save a lot of time on designing reports moving forward.
Where do you see it going a year from now?
But at every point we’ll check to make sure we’re the fastest reporting solution provider.
Stay tuned for more information on migration from C1Report and Crystal Reports!