Delphi 6 and RB7 - Data "squashes"

rbuser

Hi all,

I have a formatting problem:
I've done a report (It's actually a quotation) that is not database bound.
It's the first time I've done a report like this.

I have the following scenaio:
Main report: Header, Detail, Footer
In the Detail band I have 5 subreports - All not visible at design time, and
all "the same"

Programmatically I decide which of the reports needs to be visible,
depending the user's selections. The layout of the subreports is also
decided at runtime. There are say 10 labels on the sub-report.

TopPosition = 50
I say "label1".Top = TopPosition if item 1 was chosen, item 2 was skipped,
so it is not visible, and then if item 3 was selected, I increase
Topposition and say "label3".Top = TopPosition

TopPosition is incremented for every label as it needs to be displayed. This
is working 100% on my machine (as well as my second machine in the office).
At the customer's machines the data is "squashed" I.e. "label1".Top = 50.
"label3".top = 100 is good spacing on my machine, but on the client's
machines they are too close together (In fact they almost overlap). I used
to have the sub-report's units as printer pixels, but I changed it to screen
pixels, and the problem persists.

Anyone know how to fix this?

Incidentally I've been using RB for a few years now, but this is the first
"non data aware" report I'm doing. Is there any way to create and populate
sub-reports at runtime? I've searched the net, and can't find anything,
also - using "addObject" etc gives me Access violations. I am happy to go
with the 5 sub-report limit if I can just get the spacing sorted out.

Thanks in advance for any help.

Regards,
Gareth

digitalmetaphors

Make sure the user has a working default printer installed, otherwise, RB
uses the screen resolution. That might be causing the problem.

Here is a dynamic subreport creation example:

http://www.digital-metaphors.com/tips/DynamicSubreportCreation.zip


Cheers,

Jim Bennett
Digital Metaphors

rbuser

"Bucky" wrote in news:3dc0d58e@dm500.:



I build potentially complex reports at runtime from a tree like object
structure using templates. The dynamic subreport creation example was
very helpful.

Joanne

rbuser

Hi there,

Thanks for the subreport creation link ... It's perfect!

The "squashing" problem is still there though. I've tried the units as both
screen and printer, and the problem persists ??? They do also have a default
printer set up. (Network printer - Does that matter).

As I mentioned before I've created quite a few RB reports, but never seen
this problem - But then again I've never had to place labels etc at runtime.

I have "re-adjusted" the spacing so that it works on their machines (It's an
Intranet App only) so it doesn't have to work anywhere else, but It would be
nice if I could provide them with a real solution and not a hack.

Thanks again for the subreport info.

Cheers,
Gareth

digitalmetaphors

The screen preview is scaled because the screen is trying to show what the
printer can fit. Since the printer has high resolution it can fit more
content on the pages, and the screen has trouble fitting with less pixels.
What you can do in this case is not use a printer, but set the
Report.PrinterSetup.PrinterName to 'Screen' This way the report will
generate using the screen canvas resolution and the "squashing" should go
away for your clients.


Cheers,

Jim Bennett
Digital Metaphors


-----------------------------------------------------
Article: Why Your Preview Won't Match Your Output
-----------------------------------------------------

We have two choices when we create a preview - compose for the screen, or
compose for the printer. Most programs such as MS Word compose to the screen
when they create a preview. This makes for attractive previews but they tend
to be inaccurate. And it means that they then compose again for the printer
when you print the document. Most of the time things will print effectively
similar to the preview, but we have seen many times when the printed output
was different - a word wrapped to the next line, or some such problem. If
you use a program meant for accurate page layout, such as PageMaker, you
will notice that the Page Setup dialog asks you for which printer you wish
to compose. When PageMaker displays a page, it may not look exactly how you
think it should, but you do get a preview where the element placement is
guaranteed to match the printed output's element placement. We have chosen
to follow this second model.

Note that when we say element placement, we are referring to X and Y
placement and not height and width. While the X and Y placement of our
previews will be accurate, the height and width of text elements may vary
based on zoom percentage. This is a normal artifact of composing for the
printer and not for the screen.

Your preview can not match your printed output. It will differ in one of two
ways:

1- It can look good on the screen, but items on the page may not display in
the same location they will when printed.
or
2- It can be less attractive, but items will display on the preview exactly
where they will when printed.

We give you the second because it is more accurate and more reliable. Not to
mention more in keeping with professional page layout products.



--
Tech Support mailto:support@digital-metaphors.com
Digital Metaphors http://www.digital-metaphors.com