Interview with a Returning Customer

This is an interview with Jeff S on his experience with ActiveReports versus a competitor, and why he chose ActiveReports. GrapeCity: Is there a particular reason you chose to move to ActiveReports? Jeff: I moved to ActiveReports because of past positive experiences going all the way back to ActiveReports 2. GC: ActiveReports 2 is COM! You do go way back with us! Was there a particular feature that you needed that ActiveReports provides?

Flexible Data Binding

Jeff: The feature I needed most was the ability to bind to an arbitrary data source (DataTable or other arbitrary IEnumerable collection). Another reporting solution advertises support for that, but:

1. the documentation is lacking;
2. while it is possible, it is ridiculously difficult; and
3. the only officially supported method for this advertised feature is now officially deprecated.

Currently their own sample code for accomplishing this common task won't even build, much less run. I had to resort to using Reflection to get everything to work. GC: Wow, that must have been frustrating. In addition to the many data sources that we support natively (including the new JSON and CSV data sources), we also offer an extensive API that allows you to bind to any data source at run time, including data sets and objects. For more information, see these topics in the ActiveReports User Guide:

Bind Reports to a Data Source (Section reports) Bind a Page Report to a Data Source at Run Time

Can Grow

Jeff: Another feature I needed is something very common that, surprisingly, they simply do not support: They have an incomplete implementation of the 'Can Grow' property for their TextBox control. While it "works" in that the control will in fact grow vertically to present all the text, their report writer will NOT ALSO push nearby controls downward to accommodate the dynamic new height of the text box when it has grown. The end result is that the text in the "grown" TextBox over-writes whatever controls and text appears below. Their documentation even addresses this and clearly states vertical movement of the nearby controls is not supported. ActiveReports does, in fact, support this common scenario. GC: Yes, that is surprising. ActiveReports has supported a complete CanGrow implementation since our COM days! We also offer CanShrink, MultiLine, and WordWrap properties.

Documentation

Jeff: The biggest "feature" I wanted was clear, concise, and accurate documentation. I knew ActiveReports had that back in the day, when the product was with Data Dynamics. I have been living happily with ActiveReports 6 for several years, so I didn't keep up with the latest versions produced by GrapeCity. It appears that the documentation quality is still there. So far so good. I refer to documentation as a feature because it is what gives us (developers) knowledge, access, and insight into the product. While I cannot read the minds of the decision-makers at the other reporting solution, I can say that they seem to think that the following are sufficient for their documentation and support model:

• Sample code as a replacement for real documentation.
• Online forums to fill the gaps for EVERYTHING else (this is terribly inefficient and painful for developers).
• What documentation they do have is disorganized, outdated, incomplete, and in many cases obviously written by someone who does not understand the product.

I don't think that sample code is a good substitute for explanatory articles and real documentation. All sample code tells us is the what of how to accomplish some behavior or implement some feature. Sample code does not tell us the why of anything. Sample code is important, but by itself, it is insufficient. And even more to their detriment, their sample code is in many cases outdated and literally will not compile because it relies on deprecated or obsolete features of their report writer. And where this is the case, they have not updated the sample code to show how the technique or behavior should be accomplished with their updated APIs. Their online forums might be able to fill the gaps, if only they were monitored frequently by their staff. But they aren't. And frequently the answer is "we already addressed this question" with a link to another thread that is frequently 2+ years old. Following that thread leads to an answer that was valid for a previous version and is no longer relevant. It would be a reasonable guess to think that the other reporting solution, since being acquired by another company, is being run into the ground by investors who fundamentally do not understand technology and/or their target market; or they simply don't care and are trying to cash out by riding the momentum created by the original team who built it. GC: Thank you! We do strive to keep our documentation up to date and helpful. How many reports did you convert from the other product, and did you have any challenges? Jeff: I converted just one report. That was all I had implemented using the other reporting solution, and the experience was enough to change course. GC: Wow. What kind of reports are you creating? We're always curious to know what our customers are doing. Jeff: Orders, invoices, sales summary reports, etc. GC: Did you run into any problems creating the reports? Jeff: I had a bit of an issue coming up with the grand total in the footer based on the calculated line-item total. While I readily found the work-around, I was a bit surprised that ActiveReports does not better support this common scenario. GC: Hmm, we'll look into that for future releases. Coming from the other reporting solution, did they have any features that you are missing in ActiveReports? Jeff: No. They have nothing over ActiveReports in any way, IMO. GC: How did the converted report turn out? Did using ActiveReports add value? Jeff: The converted report is better than the other version, and ActiveReports added value specifically because the report writer correctly handles the CanGrow property of text boxes as I described earlier. GC: That's great. Thank you for your time!