Yes, I have - it's not the solution except, possibly, for removing that
particular bit of white space.

I haven't tried your method of letting R:Base move the section back
automatically, though, I didn't know that happened. I'll give it a try...

Thanks & regards,
Alastair.


----- Original Message ----- 
From: "David M. Blocker" <[EMAIL PROTECTED]>
To: "RBG7-L Mailing List" <[email protected]>
Sent: Wednesday, January 26, 2005 6:30 PM
Subject: [RBG7-L] - Re: Page Breaks - Printing


> This may be obvious Deb and Alastair, but have you tried literally
dragging
> the bottom of the section marking up as far as it will go to remove all
> white space below the controls in that section?  I mean point to the
section
> marking line until you get double arrows, hold down the left mouse button
> and drag up - I usually try to drag it BEYOND the bottom control and
R:Base
> is smart enough to jump back to the extreme position below the last
control.
>
> David Blocker
> [EMAIL PROTECTED]
> 781-784-1919
> Fax: 781-784-1860
> Cell: 339-206-0261
> ----- Original Message -----
> From: "Deb Roepken" <[EMAIL PROTECTED]>
> To: "RBG7-L Mailing List" <[email protected]>
> Sent: Wednesday, January 26, 2005 10:17 AM
> Subject: [RBG7-L] - Re: Page Breaks - Printing
>
>
> > Alastair-
> >
> > Although it may not seem believable, but I have been muddling through
this
> for 20 years too.  I was confused at first by all the white space in the
> reports and finally concluded the 'powers that be' will fix it eventually.
> It's known that the problem is with the breakpoints, and I think possibly
> with the display format mask -- when I set this, it added more white
space.
> May I please ask if you have found a workaround for the report whitespace
> problem, and if so, would you be kind enough to enlighten me.  My
customers
> are receiving their reports with lots of sheets of paper!
> >
> > Deb Roepken
> > cmri
> > 631-587-1495
> >
> >
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Alastair
> > Burr
> > Sent: Saturday, January 22, 2005 4:38 AM
> > To: RBG7-L Mailing List
> > Subject: [RBG7-L] - Re: Page Breaks - Printing
> >
> >
> > Sami, MikeB, Buddy - many thanks for all the suggestions.
> >
> > Let me try and explain the problems as best I can without taking up too
> much
> > time:
> >
> > In v6.5++ these reports produce(d) a number of text files that selected
> data
> > from a view depending on a where clause. One report in particular
produces
> > 36 output files based on the first letter of an artist's name; so: A-Z &
> > 0-9.
> >
> > They are plain text but the output filename has an HTM extension so that
a
> > browser will read them. All the HTML tags are embedded in the report
> > construction and a style sheet formats the display. There are report
> breaks
> > that not only sort the data but also pull in look-ups from other tables.
> >
> > In v6.5++ they work perfectly - at least, I've never found an error
either
> > in the presentation or the data since finishing setting them up around 2
> > years ago.
> >
> > On the basis that it was said that conversion to v7 of forms and reports
> > would all be done in the upgrade there seemed no reason to change
anything
> > that was working. A lot of work had already gone into these reports and
if
> > it wasn't broken I didn't want to mend them. Obviously where I could
> improve
> > them then that was something to do in the future.
> >
> > After 15 months using and converting to v7.x these reports work but not
> > perfectly.
> >
> > The main problems are that the amount of "white space" that seems to
> appear
> > between the various breakpoints and/or page breaks; the layout can
> suddenly
> > change in the browser for no obvious reason; and some of the text
> sometimes
> > gets repeated. Because they're intermittant problems I can't report
them.
> >
> > The "white space" was/is a problem in v6.5++ as well but in v7.x it
seems
> to
> > be inconsistent. The only problem that it causes is the file size is
much
> > larger than it need be so the browser takes longer to load it.
> >
> > The other two problems seem to be related to the layout of the report -
> > maybe the breakpoints, maybe the page set-up, maybe the printer set-up -
> but
> > something of that sort appears to be doing something odd. But remember
> that
> > they still work perfectly in v6.5++ so I can't see how it can be the
data
> > and I can't see anything wrong with the data.
> >
> > As I - and others - have said over the last year or so there is very
> little
> > help available to explain why certain features might be useful and how
to
> > use them in conjunction with other features. There is very good help
> > identifying what settings may be used for all these features but nothing
> to
> > explain why you might want to set any particular value. (Obviously some
> are
> > obvious but many are not.)
> >
> > This is particualrly true with reports. I think that it is also true
with
> > forms but, for me, trial and error along with the unending help from the
> > list has eventually taught me how to solve the use of all the form
> controls
> > that I've needed. Unfortunately, I'm not having that much luck with
> reports.
> >
> > I see, as Mike suggested, the options for other types of output but I
have
> > no idea either why I would need to use any one of them in preference to
> what
> > I am already using and no idea how to use them.
> >
> > I have thought about using a select statement to extract the data but
I'll
> > happily admit to not being capable of constructing it. But then why
should
> > I? That's what the reports are for!
> >
> > For someone that has used R:Base for around 20 years and been delighted
by
> > it until up to a year ago it is so frustrating to find v7 has so much
> > potential that is hidden behind inpenetrable features and an almost
total
> > lack of explanation. With all the help being in electronic format it's
not
> > even a problem of having to physically print manuals. I don't understand
> > why, when a change is made, the documentation is not updated at the same
> > time. It must be harder to have to go back and do it later and the
> > users/customers are likely to remain in the dark until it has been done.
> >
> > Way back in September/October 2003 I never dreampt that I would still be
> > converting to v7 fifteen months later. Changing and improving - yes, of
> > course - that's the fun part. Unfortunately, this conversion has just
been
> a
> > long, hard slog.
> >
> > Regards,
> > Alastair.
> >
>

Reply via email to