How to Display the Copy Number in a report

[mshmyob]

I am using Access 2007 but any VBA code will probably work.

I need to display which copy number I have printed.

For example if the user prints 4 copies I need to display the following in the page footer of each copy respectively:
Copy 1
Copy 2
Copy 3
Copy 4

Any ideas would be appreciated.

If you can get it to show Copy 1 of 4, Copy 2 of 4, etc that would be even better.

[MMcCarthy]

I haven't really thought about this but two things immediately pop to mind.

First one is that you will have to create a public variable to hold the total number of copies to be printed. A value which will have to be entered by the user when sending to print.

Secondly, you will need to look at creating some kind of loop in the on Print procedure of the report. Then somehow increment from one to the value stored in the public variable.

[mshmyob]

Thanks. I already ask for the number of copies so I have that as a variable in another form. So I will make it public and pass it along to the report and try and create a counter.

I don't know if the counter will clear each time a copy of the report is printed but I will give it a try and let you know.

I haven't really thought about this but two things immediately pop to mind.

First one is that you will have to create a public variable to hold the total number of copies to be printed. A value which will have to be entered by the user when sending to print.

Secondly, you will need to look at creating some kind of loop in the on Print procedure of the report. Then somehow increment from one to the value stored in the public variable.

[mshmyob]

Ok I have tried passing variables and it won't work. I think I figured out why and if anyone can figure out a better way I would appreciate it.

I open my report from a form but set the number of copies like so

Dim rpt As Report
    Dim strDefaultPrinter  As String
    ' get current default printer.
    strDefaultPrinter = Application.Printer.DeviceName
    ' switch to printer of your choice:
    Set Application.Printer = Application.Printers(strDefaultPrinter)
    ' open report but in hidden mode so you can apply parameters to it such as number of copies to print
    DoCmd.OpenReport "PickSlip", acViewPreview, , , acHidden
    ' set my parameters for the print job
    Set rpt = Reports!PickSlip
    rpt.Printer.Copies = cmbCopiesPick.Value
      ' activate my print job by unhiding it
    DoCmd.OpenReport "PickSlip", acViewNormal
     DoCmd.Close acReport, "PickSlip", acSaveNo
      Set Application.Printer = Nothing
 

This code sets the number of copies for the printer to print.
I then open the report and it prints.

The problem is that the report looks at it as printing a single report and the printer controls the number of prints.

I guess I could change the code and have say 4 lines of docmd.openrepor t and each one would be a copy but that seems very ineficient.

Anyone know any other way other than having multiple docmd.openrepor t commands.

I haven't really thought about this but two things immediately pop to mind.

First one is that you will have to create a public variable to hold the total number of copies to be printed. A value which will have to be entered by the user when sending to print.

Secondly, you will need to look at creating some kind of loop in the on Print procedure of the report. Then somehow increment from one to the value stored in the public variable.

[MMcCarthy]

I'll see if any of the other experts are aware of anything.

[Rabbit]

What if you looped the print command while at the same time incrementing a print count variable? And then calling those controls from the report?

Dim CurrentCount As Integer, MaxCount As Integer
 
MaxCount = txtMaxCount
 
For CurrentCount = 1 To MaxCount
   txtCurrentCount = CurrentCount
   DoCmd.OpenReport "rpt_Name"
Next CurrentCount
 

[Scott Price]

This is just a brain´storming suggestion since I´m not at my main computer and can´t do any testing on the computer I´m using to write this, but don´t forget the .Print method.

Again from the top of my head I´m thinking of a function that would recieve the number of copies from a public variable, and increment them, then by directly printing to the page (which is the advantage of the .Print method, doing away with the need to tie your variables to report controls) you thereby have greater and easier control over what you are wanting to do.

Just ideas, good luck, and I´ll keep an eye on this as much as I can. I´m still, unfortunately, not at a firm location yet, but will be getting back to normal in the next week.

Regards,
Scott

[NeoPa]

From my understanding of printing multiple copies of a report (using the .Copies property) it would be impossible to do what you ask as they are just that - copies.

To produce the result that you want you would need to take the approach suggested and code printing of the report n times (with one copy each time). This is slightly different as certain variables (like Print Date & Print Time would be different using this approach but exactly the same when using the .Copies approach.

To get a public variable to be accessed by an object like a report in the newer versions of Access (I don't use 2007 but I've noticed even 2003 is stricter in this than 2000 was and that was more so than 97) you will need to define a public function to return the value required. In the new versions it's probably worth designing a function with increased flexibility to handle passing various values as I anticipate it being required more with the newer strictures. I'm afraid I can't provide an example now as I'm only just starting to find some 2003 users on my databases at work. I expect I will have one in the not too distant future, but that won't help you now I'm afraid.

[mshmyob]

By the sounds of it I will need to scrap the code I have for the number of copies and use a counter loop and the openargs property to pass a variable to the report. I will re-code and let you guys know how it worked out.

It's too bad Access doesn't have the function built into the report for copies like they do for page counts.

From my understanding of printing multiple copies of a report (using the .Copies property) it would be impossible to do what you ask as they are just that - copies.

To produce the result that you want you would need to take the approach suggested and code printing of the report n times (with one copy each time). This is slightly different as certain variables (like Print Date & Print Time would be different using this approach but exactly the same when using the .Copies approach.

To get a public variable to be accessed by an object like a report in the newer versions of Access (I don't use 2007 but I've noticed even 2003 is stricter in this than 2000 was and that was more so than 97) you will need to define a public function to return the value required. In the new versions it's probably worth designing a function with increased flexibility to handle passing various values as I anticipate it being required more with the newer strictures. I'm afraid I can't provide an example now as I'm only just starting to find some 2003 users on my databases at work. I expect I will have one in the not too distant future, but that won't help you now I'm afraid.

[NeoPa]

You're showing a fine attitude here and I hope we can help you some more (or maybe even that you won't need more help) when you've adjusted your code.
However, I feel you're labouring under a misaprehension about copies. The property and the term.

1. .Copies are a property of the print and not managed by Access at all (other than to pass the request on to the printer driver.
2. A copy would NOT be a copy if it were not exactly the same. As soon as you introduce a copy counter into the printed output, it ceases to be a copy. Using the term loosely it may be used in general parlance, however the name "Copies" was chosen precisely to match the facility provided.

That's not at all to say that what you want to do can't be done, or even that you shouldn't refer to the results as copies. Just bear in mind that there will always be a level of ambiguity when terming them thus.