Board index » delphi » Re: Choosing a Report Engine

Re: Choosing a Report Engine


2008-01-10 09:26:10 PM
delphi153
Quote
One thing I miss from RB is the add on Grid Pack Add on
(www.planitechnologies.com) but that has not been updated in
quite a while.
Grid Pack Add on came with source, it was only a few lines to change for me
to get it running under RB 10.
Walter
 
 

Re: Choosing a Report Engine

Delphi VCL for native code is fully capable of creating commercial grade
applications. That is what attracted me to the Delphi product back when
Delphi 1 was released and I was evaluating developer tools to use on a
consulting engagement. The only problem back then was that I was
disappointed the available reporting solutions did not, in my mind, fully
embrace the spirit of Delphi. Thus the idea to attempt to fill that void
with the ReportBuilder product.
Perhaps you are referring to VCL.NET?
If our VCL.NET strategy was poorly articulated, then that is entirely my
fault. The important point about our VCL.NET strategy is that we spent over
6 months working on VCL.NET and had to shelve the effort due to
disappointing results. No one was more disappointed than our team, myself
included.
Here is a modified version of the canned response that includes the
important points.
"A ReportBuilder for VCL.NET product has been shelved, just prior to
completion.....Digital Metaphors will not release a product that cannot
perform up to our expectations and the anticipated expectations of
developers and end-users...We will continue to evaluate VCL.NET going
forward."
--
Nard Moseley
CEO
Digital Metaphors
www.digital-metaphors.com
 

Re: Choosing a Report Engine

Thanks for the kind words. :)
We have been working hard over the past 10 years and by collaborating with
our customers, we have been producing a product that gives them a
competitive advantage in the market place. We are trusted and responsible
partners with all of our customers - and we do not take that responsibility
lightly. I am extremely proud of the contribution we have made to the Delphi
community and the strength of the ReportBuilder community that we have
built. That is something that you do one customer at a time, day in and day
out over 10 years. There are no short cuts.
Myself and the others on the DM team are very passionate about Delphi and
ReportBuilder and about helping customers build world class reporting
solutions. We are in this business because we love it and the RB products
and community reflect that as do the past 10 years of history helping
thousands of customers and three times being voted Delphi product of year.
All RB 10 customers received a free update for Delphi 2007 support and again when
RAD Studio/D2007 Update 3 was released. With RB 10 we have 4 editions: Std,
Pro, Enterprise, Server supporting D6, D7, D2005, D2006, D2007. We have
trial and registered versions. So that makes 4 x 5 x 2 = 40 builds for each
release. Even with an automated build process that requires a big effort to
maintain. Once we release RB 11 we will not have the resources to also
upgrade all older RB versions going forward.
RB Standard and Professional include 100% of the source code - Report
Designer, the RCL (report class library), the data access classes (DADE),
and the export classes, etc. Each part of the product has a plug-in
architecture that can easily be extended. All of the dialogs can likewise be
customized/replaced. Formatting can be customized/replaced. Custom
components can be added. RB Enterprise does not include source to the
run-time Pascal environment, though the architecture includes the ability to
easily extend the environment via custom functions and custom RTTI. The
Server Edition does not include source to the server units.
You can not work the long hours that we do without loving what you do. The
software engineers required to build and support a product like RB, have to
be experts in areas ranging from data access, windows API, printing and
graphics, UI design, multi-threading, sockets, web design (html,
javascript), parser/compiler technology, I could go on and on. These people
do not work for free. How I wish the original Delphi team was still intact,
cranking out innovations - how much would that be worth to the Delphi
community?
We have a number of excellent products that we use here for which we do not
have source code: Delphi (partial source), Docomatic, FinalBuilder, and
ModelMaker, to name a few. We don't need the source to these products and
are happy to upgrade to newer versions as they become available. This
ensures that the company's behind these products can continue improving and
supporting their products. Without the company's support, the products will
die. As an example, check out the old Turbo Power products - which are open
source, but a burden to those that still try to use them without any
support - and as result are dying.
Different customers have drastically different expectations about software
products. Most fully expect that when they upgrade their Delphi version,
they need to also update the add-on components that they use.
It is impossible to have a perfect licensing model - one that makes everyone
happy and still supports a busines. Our products represent a great value -
you get what you pay for and then some. When you look at something like RB
Enterprise, you are really purchasing a report development environment
(query tools, run-time Pascal, layout designer, etc) that you can build into
your applications and distribute to your end-users royalty free. From that
perspective our products are extremely inexpensive.
I invite anyone to download a trial version and evaluate our products,
evaluate our Developers Guide, Help Docs, Tutorials, Tech Tip library,
newsgroups, and our EndUser Tutorial System/Guide that can be redistributed
royalty free. On a daily basis the engineers that work here are monitoring
the ReportBuilder newsgroups, giving quality answers - helping our customers
to build real world solutions. Most reported bugs are fixed within 24 hours,
resulting in immediately availability of a patch. Timey maintenance releases
are issued every few months.
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
 

Re: Choosing a Report Engine

The overflow errors are caused by more recent printer drivers, that have
overflow errors in them. Our latest version includes special code to work
around the overflow errors in the printer drivers. The Delphi compiler
checks for overflow errors by default and the MS compilers (that the printer
driver authors use) do not check for overflow errors by default. RB 7.04 was
released in 2004 - the problem did not manifest itself until recently.
Subreports with a PrintBehavior of pbSection automatically generate a page
break, subreports with PrintBehavior of pbChild print on the parent report's
page space - lilke memos. You can also control page breaks via Groups.
Starting with RB 9, we added a PageBreak component.
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
 

Re: Choosing a Report Engine

Quote
The overflow errors are caused by more recent printer drivers, that have
overflow errors in them. Our latest version includes special code to work
around the overflow errors in the printer drivers. The Delphi compiler
checks for overflow errors by default and the MS compilers (that the
printer
driver authors use) do not check for overflow errors by default. RB 7.04
was
released in 2004 - the problem did not manifest itself until recently.
So how do I get around the 'overflow' error? Add check code into the
application source code?
Quote
Subreports with a PrintBehavior of pbSection automatically generate a page
break, subreports with PrintBehavior of pbChild print on the parent
report's
page space - lilke memos. You can also control page breaks via Groups.
Starting with RB 9, we added a PageBreak component.
I think I should add more information on my problem:
I got just one sub-report on each 'report' page, eg. I have to print details
of each employee, there is a sub-report on each employee report page.
If I have 100 employee, I will print 100 pages and there is a sub-report on
each page. However, there may be in some cases sub-report of employee 1,
employee 2, ..., employee 10 are printed on the same page of employee 1.
 

Re: Choosing a Report Engine

1. To work around printer driver overflow errors try this..
var
lSaveCW: Word;
begin
lSaveCW := Default8087CW;
Set8087CW(Default8087CW or $3f);
try
myReport.Print;
finally
Set8087CW(lSaveCW);
end;
2. To list each employee on a separate page, create a Group on EmployeeId
and set Group.NewPage to true so that each employee will start on a new
page. On the other hand, if you are saying that sometimes for Employee X you
are getting detail for Employees X, Y, Z.. then I it sounds like an issue
with the master/detail relationship. As a test try commenting out the
event-handler code associated with the report - make sure that you do not
have any code that manipulates the dataset in any manner while the report is
generating. See the Data Access thread of our Tech Tips newsgroup for an
article on linking querys - that article explains a couple of different
techniques you can use in RB to link data.
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com