RPPro vs. RptBldr vs. QR vs. FastReport, etc.
Richard
party products but I doubt very many people have the time and money to
really check out and compare the various Report Products.
I am looking at ReportPrinter Pro and RAVE and ReportBuilder. RPPro's RAVE
looks like its advantage is being able to create projects of reports/pages
but ReportBuilder's interface seems much more powerful and versatile.
ReportBuilder has much better documentation and tutorials too.
I am soliciting testimonials from people who have compared different
reporting products. I don't want to have to purchase three or four products
in order to determine the best one.
Luiz Marques
I have looked into all the products you mentioned some ago. Note
that I only *used* QR and RB in actual projects.
Those are my impressions of each one:
ReportPrinter:
I played with ReportPrinter for half an hour and I *really* didn't
like the interface (of course, some have mentioned in these forums
that it really takes time to appreciate the new way,etc, not only I
don't want to waste this time, but my users want it even less).
FastReport:
I played with it a long time ago - it is probably much better now.
It was fairly fast and very small, and it was (and is) cheap.
What made me ignore it is that it seemed too unprofessional at the
time. It looks much better now, but I think I would still go with RB.
ReportBuilder: (what I use)
I liked ReportBuilder from the first time I saw it. The
documentation and support are very good.
Plus, if you don't want to buy the enterprise right way, you can
get the Standard or Pro version and upgrade later (some companies
charge large extras when upgrading, they charge the difference). That
was a serious factor when I got it - I first got the Standard version,
then upgraded to the Pro version (I don't feel a real need for the
Enterprise version, although I may get it later). No pressure in
getting the most expensive version up front or paying extra for the
upgrade later. I feel this reflects their trust on their product
(i.e.: they are sure you will want to spend your money later, after
you spend some time with their product and see how good it is).
If you add TExtraDevices (at www.waler.com) you get a ton of output
options.
QR:
I've used it for three years. I started looking for other tools
after getting hit by various display bugs and printing
inconsistencies. After using RB there is no way I'm going back.
_________________________________________________________
Luiz Marques s...@nospam.stg.com.br
http://www.nospam.stgsys.com [Remove nospam]
Starglider Systems
_________________________________________________________
Bernd Maierhofer
>Enterprise version, although I may get it later).
giving you the ability to code events within the report. And - wow - this
rocks!
RB is far the best and versatile Report Tool I ever came across -and I am 20
years in this business :-)
Bernd Maierhofer
dato Denkwerkzeuge
Corneliusgasse 4/5 A-1060 Wien Austria
Bernd.Ma...@dato.at
Please: No private mail unless explicitly invited.
L. S. Lichtmann
"Luiz Marques" <s...@nospam.stg.com.br> wrote in message
news:1e807tsoop5f4j8jj...@4ax.com...
>
> ReportPrinter:
>
> I played with ReportPrinter for half an hour and I *really* didn't
> like the interface (of course, some have mentioned in these forums
> that it really takes time to appreciate the new way,etc, not only I
> don't want to waste this time, but my users want it even less).
>
The time is "wasted" only if it gains you nothing. If you have anything to
do beyond a simple banded report, you will be better off with ReportPrinter
Pro, IMHO.
Luiz Marques
>>(I don't feel a real need for the
>>Enterprise version, although I may get it later).
>With the Enterprise version you get RAP, a compiler for Delphi within RB,
>giving you the ability to code events within the report. And - wow - this
>rocks!
>
>RB is far the best and versatile Report Tool I ever came across -and I am 20
>years in this business :-)
Yes, I am aware of the extra features. However, I don't feel it's
worth the extra US$250 to me.
Luiz Marques
<shrug>. I recall that the particular trial I used had very poor
documentation - if you are doing things in a non-standard way that is
particularly bad, and that is when I gave up on it.
David Mustard
stunning, ease of use admirable, support superb. They are constantly
updating and improving it - adding features and best of all involving all
the users who want to contribute. Can't think why anypne would want to use
an alternative. It constantly blows me away when you think of the
complexity contained in the packet and the simplicity of use.
Of course every package worth using requires getting used to and RB Pro is
no exception but it's totally worth it - this is no b/s. There is an add-in
TExtra Devices and another couple which are worth looking at as well
There's a trial version at the site www.digital-metaphors.com which you will
not regret trying out - it's limited in output but don't let that put you
off - it's for trying out incorporating it into your applications.
Recently they upgraded all registered Professional users to the Enterprise
version free of charge in gratitude for the support which they got from the
user base. This version surpasses everything and really is worth the extra
cash - with it your end users can actually define their own reports with a
meta language derived from Delphi and the RAP language from RB.
It has won in its category as best Reporting Tool component for the past few
years and rightly so - I can't praise it enough and clearly it speaks for
itself winning each time.
Worth a look - honest!! It's the best (am I going on too much?? <g>)
cheers - David
da...@interbears.com
"Richard" <rm...@earthlink.net> wrote in message news:3a6fd303_1@dnews...
Peck
to
> do beyond a simple banded report, you will be better off with
ReportPrinter
> Pro, IMHO.
I don't do report programming any more - my saleman does it for me now.
He's not a programmer but after reading the Report Builder Enterprise PDF
manuals,
he was able to come out with year-to-date consolidated cross-tabs (summary
and
detailed) and many more custom non-banded reports.
This was done without doing any programming effort on my part.
It was done using the Report Builder Enterprise report-writer environment.
No Delphi Professional or Enterprise was required. I do not need to
license another copy of RBE for my salemen in order for him to use it.
It's great because I delegate my reporting work to my salemen. Instead
of having multiple EXE files for each customers, now I have one standard
application and different reports for each customer.
I did evaluate Report Printer Pro, but the royalties for the end-user
designer put
me off.
At the end of the day, it's your choice. Report Builder Enterprise is a very
good investment for my company and I respect your choice for using
Report Printer Pro.
-- Peck.
David Buitenveld
being able to assemble reports from several pre-loaded clientdatasets (i.e.
developer will populate the clientdataset(s) and then invoke a report on
them).. these reports will tend to consist of lots of different sections -
some simple lists, some free-form layout, etc. Does anyone have experiences
/ thoughts on using either of these two products in this way? I have just
started playing with the Learn Reportbuilder which shows off a rather
elegant query wizard - which, unfortunately, will be pretty useless to us
because of our need to drive reports directly from clientdatasets..
thanks for any thoughts
david buitenveld
beluga software, inc.
"Richard" <rm...@earthlink.net> wrote in message news:3a6fd303_1@dnews...
Rea Berryman
powerful and flexible. It also has a very small footprint in your exe. Good luck
with your evaluation.
See-ya,
Rea
Robert Leahey (Digital Metaphors)
Remember that Learning ReportBuilder is an introductory text and application
with tutorials that we created for end users, not developers. If you've
never used ReportBuilder then it is a good place to start but it is not
meant to replace the 350-page Developer's Guide which is aimed at Delphi
developers. It's installed with the product (and the trial version) - find
it in RBuilder\Developer's Guide.
The Query Wizard you mention is part of the DADE environment (our data
access environment). DADE is meant as another avenue to data access, but
there is no reason you can't use standard Delphi data access controls on a
form. Our DADE plugins simply create TDataSets, etc. behind the scenes and
hook them to our data pipelines. Creating your own plugins is very simple -
most of the plugins on our site were created by customers. In addition, the
dataviews you see in the DADE workspace (that are created when you use the
Query Wizard or Query Designer) are part of an extensible architecture - you
can custom build your own "dataview templates" (we provide some demos) that
are specific to your populated clientdatasets. You can also extend or create
your own wizard (like the Query Wizard) and plug it into DADE.
In other words, if our existing tools don't do exactly what you want, you
could, in fact, build your own custom wizard which accesses your own custom
DADE plugin to build your own custom dataviews.
Ultimately, RB just uses our datapipeline architecture to connect to data
through TDataSource, so any TDataSet descendent will work. To get really
fancy, many people use our TppJITPipeline (an event driven pipeline) to do
unusual data access.
However, that being said, we have many users who are using MIDAS and
TClientDataSet with ReportBuilder with no problems. You might want to post a
question on our newsgroups (news.digital-metaphors.com) to ask for
impressions, as most of our users hang out there.
With regard to your layouts, ReportBuilder offers some awesome layout
capabilities. Don't let the pervasive verbiage against "banded-style" report
designers fool you, ReportBuilder will allow you to create some outrageous
layouts. Our most powerful component in that regard is probably our
free-form subreport. This allows you to nest reports within reports, create
sections (each with different printer settings) and generally create a more
"organic" feel for your pages.
When all else fails, our output architecture allows ultimate formatting:
pages are sent to output devices as a set of DrawCommands. These draw
commands can be manipulated prior to final output - edit, delete or add page
elements to tweak the page. I've seen this technique used to create pages
that looked like they came from PageMaker rather than from a report
generator.
Good luck in your search.
--
Robert Leahey
Digital Metaphors Corporation
http://www.digital-metaphors.com
***********************************************************
Please do not send messages directly to me unless I have requested it.
Please send requests for technical support to sup...@digital-metaphors.com.
***********************************************************
Eldon Yeung
mentioned tools, and finally selected Report Printer Pro. My comments are
that RPPro is the most powerful reporting tool, it is the only page/region
based (non-banded) reporting tool and can produce very professional report
pages.
On the bad side, the product has poor documentation and the learning curve
is extremely deep, especially when you want to use its code-based reporting
components. The latest version is still 3.0H Beta 4 that was released 4 or
5 months ago.
However, if you want to produce complicated reports to impress your
customers, RPPRO may be the only choice.
Eldon
"Luiz Marques" <s...@nospam.stg.com.br> wrote in message
news:v7n07tgp6afnlp6pq...@4ax.com...
> "L. S. Lichtmann" <conda...@earthlink.net> wrote:
>
> <shrug>. I recall that the particular trial I used had very poor
> documentation - if you are doing things in a non-standard way that is
> particularly bad, and that is when I gave up on it.
>
Grzegorz Wiktorowski
- code-based reports which (I guess) are nothing more than old ReportPrinter
2.0 (even dialog boxes look like created under Delphi1/W3.xx),
- programmer and end-user visual disigners.
The problem are with the latter. They have bugs and are unfinished. The last
official upgrade is 3.0G published on 1 September 1999. I don't try beta H
(published on September 2000),
because I'm not their beta tester rather their customer, but users report
problems with beta H.
In 1998 in Nevrona's advertisement I saw that ReportPrinter 3.0 would have
embedded Pascal script language. I keep Nevrona's e-mail from December 1998
where they assured the script language was ready in 95% and would be
included in moth or so. So I decided to purchase ReportPrinter in January
1999. After 2 years there is no sign of the script
language.
I work on Europe market so the end-user designer must be full language
independent. I was also assured that ReportPrinter supports international
languages. Till now not all messages can be replaced as well as wrong code
pages are used. (Don't ask me about lame beta 5 :)).
As concern Nevrona support, it's far below the avarage I receive from other
vendors. It's hard to accept that their newsgroup is not the official
support forum and customer claim (I can confirm) that messages posted
directly to tech support are ignored.
In general for me it looks like they have lost their interest in
ReportPrinter.
-----
Grzegorz Wiktorowski
OiOK
Tadeusz Golebiowski
Nevrona works very slowly, has poor support and unfinished RP3 although we
know about Rave 4.
Maybe they should to sell RAVE to Developer Express or Dream Company :-)
I'm using RP since 3 years. RP3/Rave Corporate I bougth in September/Oct.
1998. I had many promises about Rave scripting language, support Polish
language, my problems with packages. I sent many messages to the Novrona's
support but without response.
> In 1998 in Nevrona's advertisement I saw that ReportPrinter 3.0 would have
> embedded Pascal script language. I keep Nevrona's e-mail from December
1998
> where they assured the script language was ready in 95% and would be
> included in moth or so. So I decided to purchase ReportPrinter in January
> 1999. After 2 years there is no sign of the script
> language.
Without events (scripting) Rave is incomplete and weak. I bought Corporate
version, because I wanted give my users and developers end_user_designer
with full power. But without events, more reports I must make (still)
independently using Custom Connection and tricks in the Delphi (in my App).
I readed in this forum, about Report Builder Enterprise:
"I don't do report programming any more - my saleman does it for me now.
He's not a programmer but after reading the Report Builder Enterprise PDF
manuals,
he was able to come out with year-to-date consolidated cross-tabs (summary
and detailed) and many more custom non-banded reports"
It is impossible using Rave, even Corporate. More code and connections I
must write in my App (using Delphi). Without my work, my developers can make
only simple reports.
Now I can more, because I have my own solution. I have Scripter from Dream
Company, I use it with Rave with success, but I had pay additionally $350.
So, I'm still waiting for the scripting from Nevrona IN THE RAVE 3.
I'm using D5 over the year. But for the Rave packages I must still use D4,
because latest version 30Hb5 has many bugs. I have AV's and RTE 216. Stable
version 30G (1 September 1999 !!!) still using packages from D4 !!!
disappointed...
--
Tadeusz Golebiowski
tgs...@tgsoft.pl
www.tgsoft.pl
ps
sorry for my poor English
David Cornelius
is a solid, well-documented, and well-supported product. But I ran into a
couple of problems that got little more than a nod of acknowledgement from
DM.
One was minor, but still quite annoying: ReportBuilder components should be
placed only on forms (i.e. NOT DataModules). Their reasoning is that
building reports is visual and uses a lot of the form's behavior (somehow).
I never understood how a report is supposed to be like a form and so this
never made logical sense to me--I always thought it made more logical sense
to put the reports on the data module, with the data they are reporting on!
When I write web applications, there are no forms at all. (You might argue
that you don't want web applications to print anyway, but with TExtraDevices
you can generate .PDF or .HTML files.) In those cases where you need the RB
component on a DataModule (or WebDataModule), you can do it and it does
work--to a certain extent. What I have to do is keep the reports saved in
template files and load them dynamically at run time. I guess that's OK,
but their attitude about the whole thing kind-a put me off.
A more serious issue is their word-wrapping problem. Evidentially, I'm the
only person on the planet that has reported this problem and so not much
attention has been given to it. In fact, they didn't even believe me until
I sent them a sample application explaining in utter detail exactly how to
reproduce the bad output. Basically, I had a report with dozens of small,
2-line memos. Different sets of characters would wrap differently,
sometimes leaving 3/4 of the second line blank, while on the screen
everything was wrapping perfectly. IOW, I could not promise WYSIWYG. In
the end, I shipped the app hoping DM would fix the problem by the time I
started getting calls. I haven't heard from either end yet (been about 6
months).
I'll agree with others here: for banded reports on normal Windows apps, it
is truly great (except I can't put the summary band ABOVE the detail
band--even in 2-pass reports). But for the stuff I've had to do, I think I
would have rather climbed the steep learning curve with a code-based
reporting engine.
But then again, I haven't tried one yet either...
"Richard" <rm...@earthlink.net> wrote in message news:3a6fd303_1@dnews...
damian marquez
"David Cornelius" <corne...@interactivenw.com> wrote in message
news:3a75ece2$1_1@dnews...
> A more serious issue is their word-wrapping problem. Evidentially, I'm
the
> only person on the planet that has reported this problem and so not much
> attention has been given to it. In fact, they didn't even believe me
until
> I sent them a sample application explaining in utter detail exactly how to
> reproduce the bad output. Basically, I had a report with dozens of small,
> 2-line memos.
I'm not an expert but I read in RB5.53 std that memos now can be fully
justified...
is that what you need perhaps?
Robert Leahey (Digital Metaphors)
> Their reasoning is that
> building reports is visual and uses a lot of the form's behavior
(somehow).
> I never understood how a report is supposed to be like a form and so this
> never made logical sense to me
I think perhaps we have failed to adequately explain the issue behind our
suggestion to not place TppReports on TDataModules. The issue has nothing to
do with a form's behavior, rather the issue is that you can not place visual
controls on a data module. You shouldn't place TppReport on a data module
for the same reason that you can't place a TLabel on a data module.
Yes, TppReport is non-visual, but it creates visual controls and adds them
to its owner - in this case a TDataModule. In one sense, by doing this,
we're allowing you to circumvent Delphi's normal protection against such
behavior. The other reason is that in Delphi 5, the data module editor's
tree view seems to poll all the report components continuously, resulting in
sluggish performance. Both of these things are Delphi design-time issues
only. There is nothing to stop you from using a TppReport on a TDataModule
at run-time - it will be fully functional. Loading report templates is the
perfect solution to this. I'm sorry if you mistook our attitude as anything
but matter-of-fact.
With regard to word wrapping, I am unaware of any issues with this feature
and I cannot find any correspondence with you on the subject. Perhaps this
issue was handled by another member of the DM creative team? Or perhaps you
are using an older version of RB? (we're currently on 5.53) I am aware of
an issue with CharWrap - it is on our research list and should be resolved
soon. If you have some more information about this issue, please let us know
at sup...@digital-metaphors.com . We certainly don't want any un-resolved
issues hanging around.
With regard to the placement of the summary band, by nature it is the band
that is to appear last in the report. If you need a band to print summary
information before other bands have printed, you might consider looking at a
different band type. However, if you really want the Summary band itself to
print above other bands, this is possible. You should probably acquaint
yourself with our Draw Command architecture. When a page is created in
ReportBuilder, it is sent to an output device as a Page Object with a set of
draw commands. You can intercept this page object and directly manipulate
the draw commands. It would be a very simple matter to programmatically
change the locations of some draw commands to achieve the results you
describe.
One other thought: don't let the fact that we have a fully Delphi-integrated
visual designer fool you, ReportBuilder is still "code-based". How could it
be otherwise? Our report components are all VCL objects - when you select a
control in the report designer, you can edit it in Delphi's Object
Inspector, right? Your unfamiliarity with our Draw Command architecture
shows that ReportBuilder could be a much more powerful tool for you if you
research it a little more. I hope that you'll dig in and learn a little more
about the product - I think you'll be glad you did.
--
Robert Leahey
Digital Metaphors Corporation
http://www.digital-metaphors.com
***********************************************************
Please do not send messages directly to me unless I have requested it.
Please send requests for technical support to sup...@digital-metaphors.com.
***********************************************************
>
Esteban Astudillo (AxisGroup)
it seems to be that they won an award from Delphi Informant.
I'm evaluating it in this moment, hoping their RTF generation (with the
same bands approach) has a better performance than my current QuickReport
applications. Currently, I have a lot of complaints from my users because of
performance issues.
besides that, now I'm changing the way I generate the reports. Previously,
it was based on an application delivered to my users. Now, I'm creating web
application (ISAPI DLL) which comunicates with a Delphi5-VisiBroker3.3 CORBA
component, which in turn creates the reports.
so, what I think is important to consider now (thinking on internet
times), is to have a tool to create reports in a batch mode, and then create
web pages with links to them. Hopefuly, these reports will be in PDF or HTML
format directly. That's my current criteria. And I think that will be the
real challenge for Delphi tools. We have to leave the dektop, and turn to
the server..
any similar experience?
Esteban
eastu...@axisgroup.cl
"Richard" <rm...@earthlink.net> wrote in message news:3a6fd303_1@dnews...
David Cornelius
Thanks for your comments.
> The issue has nothing to
> do with a form's behavior, rather the issue is that you can not place
visual
> controls on a data module. You shouldn't place TppReport on a data module
> for the same reason that you can't place a TLabel on a data module.
I understand (and discovered myself) some of the pitfalls of designing
reports placed on data modules. Yes, most of my reports are now stored in
template files. The problems inheriting from Delphi's polling is very
interesting (and probably quite frustrating to DM)! I still don't
understand why the controls are based on the data module, though. At
design-time, a separate window is opened up for editing. Wouldn't that be
creating a whole new window (which could be based on a form) instead of
inheriting from the data module? What about the DataSet properties,
Database parameters, SQL-editors, and other components that pop up with
editable stuff? Especially Delphi's PageProducers?
> With regard to word wrapping, I am unaware of any issues with this feature
> and I cannot find any correspondence with you on the subject.
The word wrapping issue was taken up off-line with Nard Moseley back in
September. (And actually it was a combination of word/character wrapping.)
If you want the sample project, I think I still have it--or could reproduce
it quickly. I always use the latest version and eagerly look through the
bug fix list of any update to see if this problem has been addressed. After
the problem was finally acknowledge, the last I ever heard was that my
message had been forwarded to the engineer most familiar with this part of
the code.
> With regard to the placement of the summary band, by nature it is the band
> that is to appear last in the report. If you need a band to print summary
> information before other bands have printed, you might consider looking at
a
> different band type.
The summary-band-on-top came about when I was doing long web reports with
summaries at the bottom and someone wanted the summaries on the first page
so they wouldn't have to scroll through each incremental page (using
TExtraDevices). I wanted a short-cut way of either placing a first-page
link to the last page, or displaying the summary band on top. The most
obvious solution to me at the moment was to just put the summary band above
and make it a two-pass report (I think you can do that in QuickReports, but
it's been awhile...). Just today, a friend of mine was showing me a RB
report with a totals field in a group header--so I know there are other ways
of doing this.
> One other thought: don't let the fact that we have a fully
Delphi-integrated
> visual designer fool you, ReportBuilder is still "code-based". How could
it
> be otherwise?
Very true. In fact I have manipulated TppCustomComponents' positions at
run-time. But when I use a visual design tool (uh, I suppose Delphi itself
would fit into that category!), it's too easy to forget there's code
underneath and feel like you should be able to do everything with the mouse
(would this be a "Point-and-Click Syndrome"?).
> Your unfamiliarity with our Draw Command architecture
> shows that ReportBuilder could be a much more powerful tool for you if you
> research it a little more. I hope that you'll dig in and learn a little
more
> about the product - I think you'll be glad you did.
You're right, I should (and will) dig into the Draw Command architecture.
Regards,
David Cornelius
www.interactivenw.com
corne...@interactivenw.com
David Cornelius
"damian marquez" <dmarq...@hotmail.com> wrote in message
news:3a761f72_1@dnews...
Robert Leahey (Digital Metaphors)
> understand why the controls are based on the data module, though. At
> design-time, a separate window is opened up for editing. Wouldn't that be
> creating a whole new window (which could be based on a form) instead of
> inheriting from the data module?
Don't confuse the report component (TppReport) with the designer surface
(TppDesigner). TppReport contains all the report information and controls,
and for all those "code-based" enthusiasts out there it is the way to
manually code your way into report joy unexcelled. ;-) By itself, TppReport
offers no visual editing capabilities. TppDesigner is the visual workspace -
it communicates with a TppReport, gets all its information and displays it
in a visually coherent manner. The designer, however, does not own, store or
retrieve any report components. Also, when a report is previewed, no
instance of TppDesigner is created. Therefore, one cannot look at the visual
design workspace and consider it an acceptable candidate for component
ownership. What happens to the components when the designer goes away? So,
though the components are displayed and edited by the designer, it cannot
own them, neither can the TppReport component. Rather, the TppReport's owner
must own them - in this case the TDataModule - boom.
Again, this is only a design-time issue. Most people who do not want to
place TppReport on a Form will create their reports either in a compiled end
user application (if they have RB Pro or Enterprise), saving the reports to
templates. Or they temporarily create a form, place a TppReport on that in
order to edit and save the templates at Delphi design-time. Then, at
run-time, their TppReport is on their DataModule or WebDataModule and
they're loading the templates with no problem.
> What about the DataSet properties,
> Database parameters, SQL-editors, and other components that pop up with
> editable stuff? Especially Delphi's PageProducers?
Are any of these things visual controls? ;-)
> If you want the sample project, I think I still have it--or could
reproduce
> it quickly.
Sure, if you can send it again (to sup...@digital-metaphors.com ) that'd be
great. Please remember, we're human and there also exists the possibility of
technical problems - in the future, if you don't hear anything from us,
don't wait 6 months, email us again and be the squeaky wheel. We have a very
good track record of responsiveness, so if we seem unresponsive, there's
probably a problem.
> The summary-band-on-top came about when I was doing long web reports with
> summaries at the bottom and someone wanted the summaries on the first page
> so they wouldn't have to scroll through each incremental page
So what you want is not an actual TppSummaryBand at the beginning of your
report, rather you just want the summary information at the beginning.
Again, depending on the details, this should be no problem. Somewhere I have
a demo of creating a Table of Contents prior to the body of the report by
using the Two Pass technique you describe. Even if I can't find it, this is
not a difficult issue. If you want more information, email us at
sup...@digital-metaphors.com and I'll either find the demo or recreate it.
> But when I use a visual design tool (uh, I suppose Delphi itself
> would fit into that category!), it's too easy to forget there's code
> underneath and feel like you should be able to do everything with the
mouse
That's often the problem. People forget that there's 230K+ lines of code in
ReportBuilder and that ultimately, all the visual stuff is just a way of
manipulating what you could still do in code - just like Delphi. Delphi
fosters at least two kinds of users; those who never go beyond the visual
interface, and those who learn to use the convenience of the visual tools
while leveraging the power of the code. The former are still productive, of
course - Delphi (and ReportBuilder) are good enough to allow that, but the
latter are the ones who create applications (and reports) that make people
do double takes.
David Cornelius
Yeah, them being "Visual Controls" does make a big difference. There's a
lot more going on underneath than at first meets the eye.
> So what you want is not an actual TppSummaryBand at the beginning of your
> report, rather you just want the summary information at the beginning.
> Again, depending on the details, this should be no problem. Somewhere I
have
> a demo of creating a Table of Contents prior to the body of the report by
> using the Two Pass technique you describe. Even if I can't find it, this
is
> not a difficult issue. If you want more information, email us at
> sup...@digital-metaphors.com and I'll either find the demo or recreate
it.
Yeah, there are always ways around. This was a situation where the product
was basically done and going through QA when someone said, "Hey--can we have
this summary information at the top of the first page?" I had to scramble
and didn't see an quick and obvious answer. I know it'll come up again and
I'll pay more attention to it.
> Sure, if you can send it again (to sup...@digital-metaphors.com ) that'd
be
> great. Please remember, we're human and there also exists the possibility
of
> technical problems - in the future, if you don't hear anything from us,
> don't wait 6 months, email us again and be the squeaky wheel. We have a
very
> good track record of responsiveness, so if we seem unresponsive, there's
> probably a problem.
>
I will.
> > But when I use a visual design tool (uh, I suppose Delphi itself
> > would fit into that category!), it's too easy to forget there's code
> > underneath and feel like you should be able to do everything with the
> mouse
>
> That's often the problem. People forget that there's 230K+ lines of code
...
That's quite a few! What's the best resource to start getting into the nuts
and bolts of the Draw Command architecture? If I'm going to be a reports
guru, I want to dig in all the way--after all, I've been doing that with
Delphi for quite some time!
-David.
Alexis Rios (ARIOX.COM)
be better
David Cornelius
it is again...)
Thanks for the explanation on the inheritance and how RB is put together.
Yeah, them being "Visual Controls" does make a big difference. There's a
lot more going on underneath than at first meets the eye.
> So what you want is not an actual TppSummaryBand at the beginning of your
> report, rather you just want the summary information at the beginning.
> Again, depending on the details, this should be no problem. Somewhere I
have
> a demo of creating a Table of Contents prior to the body of the report by
> using the Two Pass technique you describe. Even if I can't find it, this
is
> not a difficult issue. If you want more information, email us at
> sup...@digital-metaphors.com and I'll either find the demo or recreate
it.
Yeah, there are always ways around. This was a situation where the product
was basically done and going through QA when someone said, "Hey--can we have
this summary information at the top of the first page?" I had to scramble
and didn't see an quick and obvious answer. I know it'll come up again and
I'll pay more attention to it.
> Sure, if you can send it again (to sup...@digital-metaphors.com ) that'd
be
> great. Please remember, we're human and there also exists the possibility
of
> technical problems - in the future, if you don't hear anything from us,
> don't wait 6 months, email us again and be the squeaky wheel. We have a
very
> good track record of responsiveness, so if we seem unresponsive, there's
> probably a problem.
>
I will.
> > But when I use a visual design tool (uh, I suppose Delphi itself
> > would fit into that category!), it's too easy to forget there's code
> > underneath and feel like you should be able to do everything with the
> mouse
>
> That's often the problem. People forget that there's 230K+ lines of code
Robert Leahey (Digital Metaphors)
> and bolts of the Draw Command architecture? If I'm going to be a reports
> guru, I want to dig in all the way--after all, I've been doing that with
> Delphi for quite some time!
Our Draw Commands are sort of like Delphi's OpenTools API - a powerful tool
for the serious developer that is not currently well documented. Ray
Lischner hasn't come along with a "Hidden Paths of RB Draw Commands" yet, so
for now try the following:
- The starter text would be the "Draw Command Architecture" article found in
the RCL: Component Writing thread of the Tech Tips newsgroup in our
newsgroups: news.digital-metaphors.com.
- The best resource, as usual, will be the source code itself:
TppDrawCommand is declared in ppDevice.pas while descendent draw commands
are in ppDrwCmd.pas.
- Following that, we have some demos of Draw Command usage I can send you
(We did a presentation at BorCon2K on Advanced Reporting Concepts where Tom
demonstrated some impressive uses for Draw Commands.) email us at
sup...@digital-metaphors.com and one of us will collect together some draw
command demos to send you.
David Cornelius
"Robert Leahey (Digital Metaphors)" <sup...@digital-metaphors.com> wrote in
message news:95c0sl$8l...@bornews.inprise.com...