Access "showing images on first page only of very wide Access report. Windows XP, Access XP

  • Thread starter Thread starter Jack
  • Start date Start date
J

Jack

Hi there,
I have been working on an application which is to produce reports
showing how printed material is to be arranged on a retail fixture ie
a schematic representation of point of sale material.

Background
I have created a simple blank report which is programmatically
populated with image controls. The image controls are created through
the createreportcontrol (acImage) method. These controls are sized,
named and located on the report according to data entered by the user
using options that are pre-specified. In addition each image control
has its picture path property set at the time the report is run. In
essence the report is entirely dynamic, being rebuilt from scratch
each time the report is run.

The report page (no headers or footers) is very wide at 55cm. I have
specified the print page size as A4 landscape; as a result when
previewed, the page flows over from one preview page to another.

The Problem
For development I initially used the acRectangle control type and set
the controls' backcolor to 25500, so that I could see them clearly in
the print previews. When I run the code with the CreateReportcontrol
type set as acRectangle, a print preview of the report shows all of
the controls on both preview pages.

However, when I set the CreateReportcontrol type as acImage, the image
controls show their image content (ie the picture defined by the path
passed to the picture property) on only the first of the preview pages
and not the second. Strangely, the acImage objects themselves are
visible on the second of the two preview pages (I have set their
backcolor property to 25500)

Printing the report has the same result as previewing in that the
photographic images show on the first page only, while the second page
shows the acImage controls with their color set to 25500.

Any thoughts as to why Access would be behaving in this way?

Those that have ploughed through this far, thanks very much!

Have a great day,
jack
 
In what event are you setting the Picture property of the Image Control for
each record? If you are not setting it at runtime, then what you see is not
surprising. The Print event is generally a better choice than the Format
event, simply because the Format event may fire (and execute your VBA code)
multiple times for each record.

I'm not certain that I understand why it would be needful to create the
Image control programmatically.

There are example databases (the examples use forms, not reports) you can
download from http://accdevel.tripod.com that illustrate three approaches to
handling images in Access.

If you are going to use them in reports, be sure to visit MVP Stephen
Lebans' site at http://www.lebans.com/printfailures.htm
PrintFailure.zip is an Access97 MDB containing a report that fails during
the Access formatting process prior to being spooled to the Printer Driver.

This MDB also contains code showing how to convert the contents of the Image
control to a Bitmap file prior to printing. This helps alleviate the "Out of
Memory" error that can popup when printing image intensive reports.

Larry Linson
Microsoft Access MVP
 
Larry,
Thanks for taking the time to answer...
I use an action button on another form to run the code to open (in
design view)the report, create the controls and populate the picture
properties of each of the acImage controls. There is no code module
for (within) the report, the report is the result of a stand alone
piece of code. Once all of the controls have been created (each the
result of a record in a table), the code opens the report in preview
mode.

As the report is aimed at showing on paper what a retail fixture will
look like when 'dressed' in its Point of Sale material, I need to
create the report afresh for each unique fixture in each branch.

Regarding your comments about the difference between using the print
and format events within a report: the report is not bound to a data
source, rather it is populated by controls created as a result of
looping through an external (to the report) data source. So I (think)
that the issue of Access looping through the code for each record is
non-existent.

In terms of the number of controls being created on the report, I know
that there have been an absolute maximum of 40 controls on the report.
Even in the light of comments in this Group and elsewhere about
Access' limitations with regard to showing images, I do not think that
the capacity of Access to manage the image controls is being reached.
I've had no sign of the "out of memory error".

Thanks,
jack
 
Let me see if I understand: Your report is not bound to any data... you
create multiple Image controls in the Detail section in Design View, and
assign a full-path-and-name of an image file to each.

I assume you create the Image controls because each product may have a
varying number of images.

Frankly, I've never had occasion to create a report that was not data-bound.
As an example, though I created a report that was bound only to a dummy
table with numbered records to "drive" printing that many detail sections
and populated the (predefined) controls in the detail sections from VBA
code. But that doesn't seem to be the case, here.

Still, see Stephen Lebans' site, http://www.lebans.com, specifically to
http://www.lebans.com/printfailures.htm
PrintFailure.zip is an Access97 MDB containing a report that fails during
the Access formatting process prior to being spooled to the Printer Driver.

This MDB also contains code showing how to convert the contents of the Image
control to a Bitmap file prior to printing. This helps alleviate the "Out of
Memory" error that can popup when printing image intensive reports.

If this were a case of a few images and multiple record, I'd think that
converting to .BMP might fix the problem, but since all the images are on
the same page of the report (if my understanding is correct), I'm not sure
that it will.

Larry Linson
 
Larry,
Thanks again for your time.

Larry Linson said:
Let me see if I understand: Your report is not bound to any data... you
create multiple Image controls in the Detail section in Design View, and
assign a full-path-and-name of an image file to each.
Click to expand...
Spot on.
I assume you create the Image controls because each product may have a
varying number of images.
Click to expand...

Almost. Each page is to represent a product fixture. Each fixture will
have varying amounts of printed bits of sales material (POS)
Frankly, I've never had occasion to create a report that was not data-bound.
As an example, though I created a report that was bound only to a dummy
table with numbered records to "drive" printing that many detail sections
and populated the (predefined) controls in the detail sections from VBA
code. But that doesn't seem to be the case, here.
Click to expand...

The report has only one detail section and it is the detail section
which ends up spanning multiple pages as it grows to accomodate all of
the images that the code creates on it. And it is on the pages after
the first that the images do not show, but the image controls
themselves do! (assuming that I've set the backcolor of the images
controls)
Still, see Stephen Lebans' site, http://www.lebans.com, specifically to
http://www.lebans.com/printfailures.htm
PrintFailure.zip is an Access97 MDB containing a report that fails during
the Access formatting process prior to being spooled to the Printer Driver.

This MDB also contains code showing how to convert the contents of the Image
control to a Bitmap file prior to printing. This helps alleviate the "Out of
Memory" error that can popup when printing image intensive reports.

If this were a case of a few images and multiple record, I'd think that
converting to .BMP might fix the problem, but since all the images are on
the same page of the report (if my understanding is correct), I'm not sure
that it will.

Larry Linson
Click to expand...
I've downloaded the file and will have a close look at the code to
convert images to BMPs. Thanks for the steer!

Jack
 
Back
Top