designer feature?

rbuser

I'm looking at the features in RB to see how it compares to FR4. I've been
using FR for a while now but I'm honestly fed up with their support. To say
the least, it sucks. There are a lot of nice features in FR that I don't see
in RB at a glance but I"m sure they're there somewhere. You do give us the
ability to both grow AND shrink bands which is a plus. FR does not provide
shrink. I am puzzled that its' in one property though. MS Access report
designer has both CanGrow and CanShrink for both memos and bands. They are
separate properties which makes a lot of sense. I'm lost right now without
that. The other thign I don't seen in RB is the ability to zoom in the
designer. That's something taht always frustrated me with MS Access. IT's a
really ncie plus in FR. Also, RAP is part of the base tool so there's no
additaional cost there. I've got a lot of reports in FR right now and not
sure if switching at any point makes sense but the quality of support over
there is really making me question my decision of 2 years ago. Probably more
questions to follow.

Thanks,

Keith

nicocizik

Hi Keith,

Thanks for trying ReportBuilder and welcome! I'll be happy to answer any of
your questions.

1. All bands except the page footer have the ability to grow or shrink with
the dynamic height (stretchable) components that may reside inside them.
This can be controlled using the Band.PrintHeight property. Setting this
property to phDynamic will enable the band to stretch.

Note there are certain objects that have the ability to stretch such as the
TppMemo, TppRichText, TppRegion and TppSubreports. In order to make these
components stretch, you will need to set their Stretch property to True.

2. Zooming in the designer is something we would like to add to our product
very much. The main problem is that the designer was not initially designed
to support this type of action and would require a complete re-design to do
so. Over the last few major releases we have started breaking apart the
designer code and refactoring it piece by piece. This however is a huge
undertaking and must be done in phases. It is currently on our todo list to
support zooming in the designer for a future release.

3. RAP is included with the Enterprise edition of ReportBuilder. RAP is
more than a scripting utility. It is a complete report programming IDE and
language modeled after Pascal that is compiled within RB and enables you to
keep your event and other report code local to your saved report
template(s). It is also extensible allowing you to add more functionality
or even create Delphi pass thru functions to work with your reports. For a
complete description of RAP take a look at the following web page...

http://www.digital-metaphors.com/products/RAP/what_is_rap.html

Let me know if you have any more questions.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Keith G Hicks wrote:


You will be in for a shockingly pleasant change then as DM support is
first class. The product is very good and well documented with lots of
examples out there. Many of us would like to see a .Net edition, but
they are working on it.. and we are in fact, stalling our .Net
development a bit waiting for RB.Net. That is how much we depend on
this tool.

--
David Farrell-Garcia
Whidbey Island Software, LLC

rbuser

hi david,
i am still in the first few months of being registered user of RB. I
have had similar background to yourself in that we have many (with other
VCL based report engines i shaln't name here) reports in our
applications and wanted to switch to one. In our case mainly to make it
easier distributing an end user tool so our clients can make/adapt their
own reports.

my experience is that the RB documentation is superb, eg the tutorial is
an example for all software manufacturers & that includes us.
Using the designer, it seems very good, positive, clean and everything
seems there i think. things that used to frustrate me in other tools
such as complex page numbering (page of pages within groups) is easy in RB.

My one sticking point with RB is that it seems so difficult to simply
print report selection criteria on a report. so if you need this feature
i would ask them about this & try to do it yourself. it appears not
possible without going into RAP programming and that of course means end
users may have difficulty designing real-world reports. I dont think we
should have to upgrade to enterprise (to get RAP) and go to such lenghts
just to print something simple like "This report is for date n to y").
Surely?

see the thread in the end-user newsgroup, for which i am still awaiting
an answer... Re: How to display Selection Criteria in Report
dean robinson
Pearce & Robinson LTD
www.transactor.co.uk
Skype phone username DeanWMR

rbuser

DeanWMR wrote:

I have heard that controversy over the years and can only say that I
only agreed with it when I did not have the Enterprise edition :-)

I am not sure what you mean by "it seems so difficult to simply
is much more then a simple scripting tool. it is a programming language
that gives the designer (and knowledgable end-user) way more reporting
power then you could ever get from a simple scripting language or
anything that you could set in a property sheet in the designer.


Actually, when you compare the price of RB with other big name report
tools such as Crystal and ActiveReports (for .Net) RB Ent is actually
cheaper. I think you have to think of RB Enterprise as the only full
featured edition of RB and that if you don't need RAP then and only
then do the lesser editions make sense.



--
David Farrell-Garcia
Whidbey Island Software, LLC

nicocizik

Hi Dean,

There is now a response to your thread in the End-User newsgroup. Sorry for
the delay.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

hi david,
comments noted and appreciated. i dont have a problem with the price, i
will be upgrading as soon as i get some project time to do some
integration with our app, and build a DataDictionary-aware end-user
report-designer that is tailored for our application's database so our
users can easily do add-hoc reports and modify existing ones.

My concern was that after getting RAP, i can still hear the support
phone.. 'i've just made a report of [...] for a selected department how
do i show the selected Dept on the report header'. The latter is the
crutch of it; of course back at base, armed with RAP, Delphi and The
programmers guide to the Universe we're able to use RAP to do it. I just
wondered if it were better for a Report Selection Criteria,(oddly named
Auto-Search Fields in RB) to be simply available in the designer, as a
parameter value, for putting on the report header.
best regards, dean

rbuser

DeanWMR wrote:


No question about it. You will get those calls. Make sure that you
sell RAP to your customers as a programming tool that can be used by a
knowledgable end-useror or that they must pay you a fee to do custom
RAP enabled reports. The idea is that most end-users can build great
reports without RAP. If they have a need that exceeeds what can be
done with the standard RB tools then the capability is there. That
simply is not true with all reporting tools.

We always use RAP in our application, instead of using event handlers
in the application itself to allow for this flexibilty. This also
helps because we store all customer report templates to a central
database and RAP stores along with the report but application event
handlers do not.



--
David Farrell-Garcia
Whidbey Island Software, LLC

rbuser

hi again. thats interesting & i do see your point. yes i'm also in
favour storing templates in the DB centrally. Re the main issue, we do
have some v. skilled IT end-users but most are not. i don't think we can
throw a RAP programming manual at the latter group when they want to
print their report's date range on the report. you may say that even
other visual designers need IT skills, a knowledge of relational dbs etc
so whats the problem. well i think that the RB visual designer is
excellent, and can almost do all that i envisage my users will need
without RAP programming. i just don't see why RB hasnt got that
tini-weeni little functionality to allow us & end-users to insert a
Selection Parameter on a report hdr. its like this data is hidden. And
no i am not plumbing for more-and-more features leading to bloatware.
i'm against bloatware/endless features/all-things-to-all men mentality.
thats a sorry road for any s/w product to go down. In a way, i'm asking
for the opposite. if that little bit of expected functionality [sic] was
in the core product(as it is in ALL the other V designers i can think of
- and for good reason), then i dont need to distribute the RAP modules
with its 975 functions and 10 chapter-instructions.

perhaps, i shall put this issue on hold a while, finish my current
project and get back to you guys. in the meantime i shall go see a shrink.
deanWMR www.transactor.co.uk