Solved

Different result when printing after previewing a report

Posted on 2003-11-22
12
286 Views
Last Modified: 2008-02-26
I have a report that I start from a cmd button in preview mode. If I then print the report, I may get different results from what the preview screen showed.

The report runs some vb code started from the detail on format and on print events. There are also sub-reports that do the same. The code that gets called from these events, sets the visible property to false for controls that are empty (code courtesy of Steveb and 1William).

Public Function ControlDisplay(rpt As Access.Report)
Dim ctl As Control
Dim stTest As String, stTest1 As String
    On Error Resume Next 'not all controls will have datasource (line for example)
    For Each ctl In rpt.Section(acDetail).Controls
        ctl.Visible = (Len(ctl.Value & vbNullString) > 0)
    Next
End Function

It seems that if, on a sub-report, there are 2 records and the first record has all controls populated but the 2nd record doesn't have all controls populated, that the all the controls/labels get printed anyway. It's wierd because the first time you preview then print, the empty controls print, but if you preview/print again, it's ok.

Any ideas?

ps, I did a work around, and have separate print and preview command buttons, which seems to be working ok.
0
Comment
Question by:avoorheis
  • 7
  • 5
12 Comments
 
LVL 23

Expert Comment

by:heer2351
ID: 9805697
You would only have to call the above code from the onFormat event of you report. No need to call it again from the onPrint event.

Could you post the code of the onFormat event so I can have a look?
0
 

Author Comment

by:avoorheis
ID: 9808491
It's the same code that's called from both the on format and on print.

At first, I just had the on format calling the code. And did a print preview, all looked ok. But then when trying to print (preview still displayed, using print icon in toolbar), it didn't print right. If printed a second time, it printed ok.

I tried it again with only using the on format event and if I use
DoCmd.OpenReport stDocName, acViewNormal (instead of acPreview) it prints ok, but it still does the same thing if I use acPreview (preview looks ok, but the first pass print is not ok, using the print icon in the toolbar).

Hope I'm being clear. This only happens when when the subform has 2 records and some of the fields on the second record are empty (so should not display). I'll try an example of the report printout:

this is how it should look

          SAMPLE GOOD REPORT
Date:            1/1/03
Order#:        12345
Mortgage #:  1                    (start of subreport)
Grantor:        John Doe
Date:            1/1/03
Assigned To:  B of A
Mortgage #:   2
Grantor:         Sam Smith
Date:             2/1/03

         SAMPLE WHEN FIELD PRINTS WITH NO DATA
Date:            1/1/03
Order#:        12345
Mortgage #:  1
Grantor:        John Doe
Date:            1/1/03
Assigned To:  B of A
Mortgage #:   2
Grantor:         Sam Smith
Date:             2/1/03
Assigned To:

The "Assigned To:" should not show up because it didn't have data.

0
 
LVL 23

Expert Comment

by:heer2351
ID: 9813402
To help you I will need to look at the code, could you please post this.
0
 

Author Comment

by:avoorheis
ID: 9813479
The on format event for the main report detail and the on format for each sub report detail calls:

Public Function ControlDisplay(rpt As Access.Report)
Dim ctl As Control
    On Error Resume Next 'not all controls will have datasource (line for example)
    For Each ctl In rpt.Section(acDetail).Controls
        ctl.Visible = (Len(ctl.Value & vbNullString) > 0)
    Next
End Function
0
 
LVL 23

Expert Comment

by:heer2351
ID: 9813638
Hmm I am not able to reproduce your problem.

Let's check if the code is called when doing a print after doing a preview, place a breakpoint in the ControlDisplay function on the on error resume next line. Now preview the report you should stop in the code, hit F5 to continue running. Then click on print, are you again taken to the code?
0
 

Author Comment

by:avoorheis
ID: 9813811
I was doing that the other day and just did it again. When I print, it doesn't stop at the breakpoint. But, I put a beep right after the line where the break is. I hear the beep when I print (so it's like it goes throught the code) but it doesn't stop at the break.

When I do the preview, it stops 6 times (and beeps 6 x) at the break, but when I print there's only one beep (but doesn't stop). Also, I do the preview, I see it looks format correctly, then print and it's not formated correctly. If I print, right away, again, it's formated correctly. ????????????

(there are 4 subreports, so I expect more than 1 stop, but 6 doesn't make sense either
0
Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

 
LVL 23

Expert Comment

by:heer2351
ID: 9813828
Hmmm very strange, would you mind sending a zipped version of your database to me so I can have a look?

heer2351 at hotmail.com
0
 
LVL 23

Expert Comment

by:heer2351
ID: 9820556
Alan I had a look at your database. The reason for the onPrint event not being fired is that you did not set the event handler, i.e. open the report in design view and have a look at the events tab you will see that the onPrint is empy. You probably copied the onFormat event and renamed it, access does not like that. If you cut and copy the already renamed event access will set the event handler. But like I said before it is not required.

I have not yet solved your problem, but I am thinking that the problem is due to the fact that the subreport is part of a footer instead of the detail section.
0
 

Author Comment

by:avoorheis
ID: 9820682
Do you think, as a general rule, it would be better to use the main reports, footer onformat event instead of the subreports, detail onformat event?

As far as the onPrint event, I was going back and forth with using/not using the onPrint event, so the code was there and I just disabled it by deleting the Event Procedure. Since onPrint event is not needed, does Access actually run through the code a second time if you print while previewing the document?
0
 
LVL 23

Accepted Solution

by:
heer2351 earned 250 total points
ID: 9820893
I think I have found the solution to your problem. Change in your onFormat event the line:

ControlDisplay Reports("reportName")
or ControlDisplay report_subreportName

with
  ControlDisplay Me

That solved the problem for me :)
0
 

Author Comment

by:avoorheis
ID: 9821291
Thanks!
Do you have any idea why?
I haven't used Me by itself before and couldn't find anything in the help files. Do you know of any documentation about it?

thanks again
0
 
LVL 23

Expert Comment

by:heer2351
ID: 9821345
My guess is that when then function is called for the second record on the subreport time access created a new instance of your report that has a different name as the first report instance. Because you only refer to this first report all records will have the same controls made visible as the first record.
By using Me you are sure that you are refering to the correct instance of the report.

From the help:

<quote>
The Me keyword behaves like an implicitly declared variable. It is automatically available to every procedure in a class module. When a class can have more than one instance, Me provides a way to refer to the specific instance of the class where the code is executing. Using Me is particularly useful for passing information about the currently executing instance of a class to a procedure in another module. For example, suppose you have the following procedure in a module:

Sub ChangeFormColor(FormName As Form)
      FormName.BackColor = RGB(Rnd * 256, Rnd * 256, Rnd * 256)
End Sub

You can call this procedure and pass the current instance of the Form class as an argument using the following statement:

ChangeFormColor Me
</quote>
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Today's users almost expect this to happen in all search boxes. After all, if their favourite search engine juggles with tens of thousand keywords while they type, and suggests matching phrases on the fly, why shouldn't they expect the same from you…
Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now