Report loads fine with all data correct but will not print the data!!

  • Thread starter Thread starter Alex Richards
  • Start date Start date
A

Alex Richards

Hi everyone,

This problem really has me baffled. I just don't know
what it could be.

From the start....I have created a completley unbound
access project using ADO recordsets including forms
reports etc.

I have all my reports working apart from one. This is the
problem, initially the form loads with the data displayed
correctly..this is fine. I then click on my print button
which then loads my report in print preview mode.

The report consists of 4 sub-reports, all sub-reports are
hidden when the report_Open is called. The in the
report_activate it calls a function within a module which
works out how many sub-reports to display (visible = true)
depending on the criteria selected by the user on the main
form. This then in turn calls a series of other functions
to get the recordset populate the sub-reports etc. THIS
ALL WORKS WITH NO PROBLEM....


The report loads up with no problems atall all data is
displayed in the sub-reports consisting of just numbers.

The problem comes when you try to print the report. The
report prints fine all sub-reports print but they are
empty, there are just NO NUMBERS VISIBLE even though they
are displayed on the screen in print preview mode!!! This
is just weird...I use these sub-reports in other reports
and they print fine!!

I think it might be because I am calling so many functions
that somehow it is getting confused...just a guess...I
don't know how I can get around this without calling the
functions though!

I would really appreciate any help on this as I have
finsihed my project and this is the only thing stopping me
from releasing it. This report is the most important in
the project!!

Thanks in advance,

Alex Richards
 
Alex said:
From the start....I have created a completley unbound
access project using ADO recordsets including forms
reports etc.

I have all my reports working apart from one. This is the
problem, initially the form loads with the data displayed
correctly..this is fine. I then click on my print button
which then loads my report in print preview mode.

The report consists of 4 sub-reports, all sub-reports are
hidden when the report_Open is called. The in the
report_activate it calls a function within a module which
works out how many sub-reports to display (visible = true)
depending on the criteria selected by the user on the main
form. This then in turn calls a series of other functions
to get the recordset populate the sub-reports etc. THIS
ALL WORKS WITH NO PROBLEM....


The report loads up with no problems atall all data is
displayed in the sub-reports consisting of just numbers.

The problem comes when you try to print the report. The
report prints fine all sub-reports print but they are
empty, there are just NO NUMBERS VISIBLE even though they
are displayed on the screen in print preview mode!!! This
is just weird...I use these sub-reports in other reports
and they print fine!!


I suspect that this problem is because you're using the
Activate event to maipulate the report. Activate only fires
in Preview mode, it will not be called in Print mode. Try
using the Open event instead.
 
I suspect that this problem is because you're using the
Activate event to maipulate the report. Activate only fires
in Preview mode, it will not be called in Print mode. Try
using the Open event instead.

Hi Marsh,

Thanks for your response. The problem with using the open
event is that access will not allow you to populate the
text boxes within reports using an ADO recordset because
you do not have the recordsource set (unbound). The only
way in which access will allow the population of text
boxes using an ADO recordset is if you set them on the
activate event.

List boxes on the other hand require you to use the on
open even to poulate them using an ADO recordset, text
boxes require the on activate event....don't ask me
why!! :-)

I have many other reports using this on activate method to
populate the text boxes and they print fine. I am really
confused as to why this is happening!!! Could it be to do
with I am using a function within a module to get the
recordset then calling another function to then populate
the text boxes??

Any other suggestions you may have would be much
appreciated.

Thanks once again,

Alex Richards
 
Thanks for your response. The problem with using the open
event is that access will not allow you to populate the
text boxes within reports using an ADO recordset because
you do not have the recordsource set (unbound). The only
way in which access will allow the population of text
boxes using an ADO recordset is if you set them on the
activate event.

List boxes on the other hand require you to use the on
open even to poulate them using an ADO recordset, text
boxes require the on activate event....don't ask me
why!! :-)

I have many other reports using this on activate method to
populate the text boxes and they print fine. I am really
confused as to why this is happening!!! Could it be to do
with I am using a function within a module to get the
recordset then calling another function to then populate
the text boxes??


I don't use ADO so there may be something different than
what I'm familiar with, but I don't think it could be that
drastically different.

Granted, the Open event is too early to assign values to
controls, but the Activate event is only supposed to fire
when the report window becomes active. Since there is no
report window in print mode, the event should never fire.
You can easily check this by placing a msgbox in each event
and then noting what happens as you open the report in one
mode then the other. The Activate event is only there so
you can do something special for on screen viewing,

I typically use the Format event of either the report header
section or the section containing the controls to assign
values to unbound text boxes.

Most(?) properties, other than Value, can be set during the
Open event (some can only be set in the Open event), so that
may be where the perceived inconsistencies arise.
 
Back
Top