Hmmmmmmmmmm,
for the "first":
an "independent" module. The declaration -at least- needs to be seperate fron the rest. The function COULD go in a report, but I like to keep the declaration and calculation together. It COULD get weird if there were multiplie users using the same routine for seperate reports at the same time?
Code:
Option Compare Database
Dim CopyCount As Integer
Public Function basCopyCount() As String
'Michael Red 10/17/2001
'To "Mimic" the multi-part form where each 'copy'
'is on a different color of paper.
If (CopyCount > 3) Then
CopyCount = 1
End If
Select Case CopyCount
Case Is = 1
basCopyCount = "Original"
Case Is = 2
basCopyCount = "Yellow Copy"
Case Is = 3
basCopyCount = "Blue Copy"
End Select
CopyCount = CopyCount + 1
End Function
As you may be able to discern, this returns a "string" re the "Copy", and incerments the "Copy" counter. The actual assignment of the string to something on the report is done in the report iteslf.
In this example, the process just 'mimics' the multipart form for the different colors of the various copies, so it should just 'cycle' through the "colors". Here, the report needs to be opened in code, al-la"
docmd.OpenReport "rptTournament", acNormal,, CopyCount = 3
which SHOULD print three copies of the report. As noted in the module, it has been a while since I did this one, and the time has 'rotted' the code which I used to demo the process, so the above sample command may be a bit simplistic!
For the second ver which you were really after, the mechanics are more than I am interested in throwing out 'pro bono', but the approach I would take would require at least the creation and manipulation of registry settings, and -if you are serious about the 'charge' for each use, it would also need some fairly robust security. However oncce past these hurdles, the basic approach is to just increment a counter for each instantation of the 'chargeable' objects. Going really out there, you could even have seperate counters for different "groups" of objects, thus charge more for some than others (presumably based on the complexity or development investment).
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over