UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Print A Report Behaves Differently From Preview., Access 2016    
 
   
tbacon_nz
post Feb 9 2018, 09:58 PM
Post#1



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


I have a report that has some code in the detail_print event.

If I preview the report, i.e.
CODE
Docmd.openreport"myreport", acviewpreview

then the on detail_print stuff executes and it displays correctly.

If I print it with this code:
CODE
    DoCmd.OpenReport "myreport", acViewPreview,,,acHidden
    DoCmd.SelectObject acReport, "myreport"
    DoCmd.RunCommand acCmdPrint                             'so I can set some parameters
    DoCmd.Close acReport, "myreport"

The report prints but the detail_print manipulation doesn't happen.

If I print the report directly, i.e. without the intervening AcCmdPrint, it prints as it should.

Any suggestions gratefully received.

Go to the top of the page
 
GroverParkGeorge
post Feb 10 2018, 06:34 AM
Post#2


UA Admin
Posts: 31,911
Joined: 20-June 02
From: Newcastle, WA


What exactly are you expecting to happen with these two lines of code?

DoCmd.SelectObject acReport, "myreport"
DoCmd.RunCommand acCmdPrint

The reason I ask is that I've not really seen that approach used....

I would imagine, though, that if you want to manipulate the report prior to printing it, you'd have to open it in design view, and hidden, not just hidden and already in print preview.
This post has been edited by GroverParkGeorge: Feb 10 2018, 06:45 AM

--------------------
Go to the top of the page
 
pere_de_chipstic...
post Feb 10 2018, 09:56 AM
Post#3


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


I have used select object method to print out a report with the Printout command:

e.g.
CODE
    DoCmd.SelectObject acReport, "MyReport"
    DoCmd.PrintOut acPrintAll, , , acHigh, 2, 0
    DoCmd.Close acReport, "MyReport"


The 'Printout' command prints the object selected by the SelectObject command.

hth

--------------------
Warm regards
Bernie
Go to the top of the page
 
GroverParkGeorge
post Feb 10 2018, 10:15 AM
Post#4


UA Admin
Posts: 31,911
Joined: 20-June 02
From: Newcastle, WA


Thanks. One is never too old to learn new things.

What is the advantage of doing it this way over simply printing the report?

--------------------
Go to the top of the page
 
pere_de_chipstic...
post Feb 10 2018, 11:02 AM
Post#5


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Now that, George, is a good question!

This was some while ago, but if IIRC, if I want to print to a specific printer, but not show the report being previewed, I needed to open the report hidden, set the printer and then use the Selectobject command to select the report before it could be printed. If I didn't, then the form which had the focus when the print command was used would get printed instead, which was quite frustrating (especially to my clients!)

--------------------
Warm regards
Bernie
Go to the top of the page
 
GroverParkGeorge
post Feb 10 2018, 12:57 PM
Post#6


UA Admin
Posts: 31,911
Joined: 20-June 02
From: Newcastle, WA


Ah, not the report itself but the printer. Thanks. The light comes on.

But couldn't you change the printer for the report instead of leaving it set to the default?

--------------------
Go to the top of the page
 
pere_de_chipstic...
post Feb 10 2018, 03:14 PM
Post#7


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


The reason I don't set the printer in each report's setup is for flexibility.

I usually don't know what printers / printer drivers my clients will be using while I'm developing the database so I set all the reports to use the default printer. A printer set up form allows the user to define which printer they want each report (or set of reports) to go to. They can then (e.g.) route some reports to a colour printer, others to a black and white printer, or others to a label printer. See this code archive post

The other advantage is it will allow the user to change (e.g.) speciality printers without needing the report to be redesigned.

--------------------
Warm regards
Bernie
Go to the top of the page
 
tbacon_nz
post Feb 10 2018, 05:08 PM
Post#8



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


Thanks everyone for the feedback.

The reason I do

CODE
DoCmd.SelectObject acReport, "myreport"
DoCmd.RunCommand acCmdPrint


is to make "myreport" the active object, then display the printer dialog so I can set parameters (printer, paper source etc) - and when I click OK in the printer dialog it prints the currently active object (as I understand it).

I am actually printing labels, and the manipulation in the detail_print event is to skip over a predefined number of labels before printing, so as it is dynamic it has to be done at run-time rather than in report design.

Feel free to tell me there is a better way.
Go to the top of the page
 
pere_de_chipstic...
post Feb 10 2018, 05:44 PM
Post#9


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Hi

You should be able to use the following code (air code) in the reports Detail_Print and ReportHeader_Format events
CODE
Option Compare Database
Option Explicit

Dim BlankCount&
Dim CopyCount&
Dim LabelCopies As Integer

Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

    If BlankCount& < BlankRecords Then
        Me.NextRecord = False
        Me.PrintSection = False
        BlankCount& = BlankCount& + 1
    Else
        If CopyCount& < LabelCopies Then
            CopyCount& = CopyCount& + 1
            If CopyCount& < LabelCopies Then Me.NextRecord = False
        Else
            CopyCount& = 0
        End If
    End If
    
End Sub

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As Integer)

    Dim strArgs() As String
    
    strArgs() = Split(Me.OpenArgs, "|")

    'Reset for printing after preview
    BlankCount& = 0
    CopyCount& = 0
    
    BlankRecords = CInt(strArgs(0))
    LabelCopies = CInt(strArgs(1))


End Sub


The report header code is is needed to reset the variables for printing after a report preview. I use the report's OpenArgs parameter to pass the number of blank labels and the number of copies of each label to the report (NB code sample is from memory and not tested - it might need some tweaking!)

hth

--------------------
Warm regards
Bernie
Go to the top of the page
 
tbacon_nz
post Feb 11 2018, 07:42 PM
Post#10



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


Thanks for the code sample. That is actually pretty much what I am doing. The issue is not getting the report to skip the labels, which it successfully does when I preview it, but for that same code to kick in after I click OK in the print dialog, which it isn't (apparently).
Go to the top of the page
 
pere_de_chipstic...
post Feb 12 2018, 03:46 AM
Post#11


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Is the 'reset' code in the reportheader_format event and, in the report design mode does your report show the report header and does the report header have the appropriate event set up?

--------------------
Warm regards
Bernie
Go to the top of the page
 
pere_de_chipstic...
post Feb 12 2018, 03:56 AM
Post#12


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Ps if the 'reset' code is in the report open or on load events then it will not fire when the report is printed after preview.

--------------------
Warm regards
Bernie
Go to the top of the page
 
tbacon_nz
post Feb 12 2018, 05:01 PM
Post#13



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


Thanks for the update. I thought you'd nailed it as I didn't have any code in the report_header_format event, but it is still not working. I put in breakpoints and everything is getting triggered when I preview, and the preview (if I unhide it) shows the correct layout, but nothing is triggered after I click "OK" in the AcCmdPrint print dialog and nothing gets skipped.

This is the relevant code:
1 - in the "print" on click event
CODE
Private Sub Command5_Click()
      
    DoCmd.OpenReport "labels2", acViewPreview, , ,achidden, Me.NumToSkip
    DoCmd.SelectObject acReport, "labels2"
    DoCmd.RunCommand acCmdPrint
    DoCmd.Close acReport, "labels2"

End Sub

2- in the report
CODE
Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

    If BlankCount& < BlankRecords Then
        Me.NextRecord = False
        Me.PrintSection = False
        BlankCount& = BlankCount& + 1
    End If
    
End Sub

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As Integer)

    'Reset for printing after preview
    BlankCount& = 0
    
    BlankRecords = Me.OpenArgs

End Sub

I'm obviously missing something, but what?
Go to the top of the page
 
pere_de_chipstic...
post Feb 12 2018, 06:23 PM
Post#14


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Hi

I've not used the technique you are using to access the print dialog box, and as I don't have A2016 I wouldn't be able to look at your database and report. As nothing is triggered I wonder if using acCmdPrint may be the reason. I'll set up a test scenario here to see if I can emulate the problem - but that will have to be tomorrow (UK time!)

Have you tried setting up the printer parameters before you open the report using the technique described in my earlier post in the link to the code archive. You would then be able to directly print the report and not need to preview the report to open the print dialog.

--------------------
Warm regards
Bernie
Go to the top of the page
 
pere_de_chipstic...
post Feb 13 2018, 06:53 AM
Post#15


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


Hi

I've set up a report to try to emulate the error you are having.
In the report code module I have:
CODE
Option Compare Database
Option Explicit
Dim BlankCount&

Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

    If BlankCount& < BlankRecords Then
        Me.NextRecord = False
        Me.PrintSection = False
        BlankCount& = BlankCount& + 1
    End If
    
End Sub

Private Sub ReportHeader_Format(Cancel As Integer, FormatCount As Integer)
    Debug.Print "BlankRecords = " & BlankRecords
    BlankCount& = 0

End Sub


In this case I have set a a global variable 'BlankRecords', which the user enters via an input box.

my code for opening the report is:
CODE
Public Function TestRpt()
    DoCmd.OpenReport "rptNameLabels", acViewPreview, , "MemberID = 812", acHidden
    DoCmd.SelectObject acReport, "rptNameLabels"
    DoCmd.RunCommand acCmdPrint
    DoCmd.Close acReport, "rptNameLabels"
End Function


All I have done here is to change the report name and add a filter; this works as I would expect, with the one name label printed in the required label position.

--------------------
Warm regards
Bernie
Go to the top of the page
 
tbacon_nz
post Feb 14 2018, 04:02 AM
Post#16



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


Thanks for all the help. I haven't had a chance to look at it today - I'll get on to it tomorrow.

BTW where on "South Coast, England"? I was in Southampton before I fled to New Zealand (via Australia) in 1974.
Go to the top of the page
 
tbacon_nz
post Feb 14 2018, 04:13 PM
Post#17



Posts: 216
Joined: 6-February 03
From: Waiatarua, Auckland, New Zealand


This is so embarrassing.
It looks like the whole thing is down to poor coding and insufficient checking n my part.

I applied your fix and it worked - hooray! But I couldn't understand why that was OK but when I was taking the data directly from the input form (i.e. forms!formname!fieldname) it wasn't. When I looked properly closely I realized I wasn't picking up the input field because of coding finger trouble. I hadn't noticed because Access hadn't flagged it as an error at compile time. I fixed that and whaddyaknow - it all worked.

I am so sorry to have put you to so much trouble. I can only blame the fact that I am only a very occasional Access coder these days and hadn't been near it for quite a while.

Thanks again for all your help.
Go to the top of the page
 
pere_de_chipstic...
post Feb 17 2018, 06:10 AM
Post#18


UtterAccess Editor
Posts: 10,130
Joined: 8-November 07
From: South coast, England


No worries, that's happened to all of us - me included!
Glad you have it sorted and pleased to have been able to help.

Good luck with your project.

Ps: my 'south coast' is near Christchurch, but just inside the Hampshire border on the edge of the New Forest. Quite envious of you in NZ, I spent 6 months working there, based in Wellington, but some years ago, loved it. Hope to visit again someday.

--------------------
Warm regards
Bernie
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    19th February 2018 - 02:38 PM