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

"Jack" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

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

"Larry Linson" <(E-Mail Removed)> wrote in message news:<utZ8Qy$(E-Mail Removed)>...
> 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

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


"Jack" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
> "Larry Linson" <(E-Mail Removed)> wrote in message
news:<utZ8Qy$(E-Mail Removed)>...
> > 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 again for your time.

"Larry Linson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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.
>
Spot on.

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

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.

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
>
I've downloaded the file and will have a close look at the code to
convert images to BMPs. Thanks for the steer!

Jack