Hi Brent,

When performing tasks of similar nature I like to declare a global
constant (eg: Global Const gstrTitle as String = "Some text Here" &
vbcrlf & "Second line here") especially when the value changes so
rarely. Declaring it as a constant will save you having to declare the
value at startup. Alternatively, you could store the string in a number
of locations ie: external file, custom properties, table etc. I would
be interested to learn why your teachers have told you not to declare
global variables. Anyway, if you need more information to help you with
this task let me know.

Anton

Per Brent Ritchie:

I'd wrap the global in a function and then call the function.

e.g.

-------------------------------------------------
Const gWhatEver = "xyz"
-------------------------------------------------


-------------------------------------------------
Public Function CommonReportHeader() As String

CommonReporHeader = gWhatEver

End Function
--------------------------------------------------

--------------------------------------------------
Report_Open()
Me.txtReportHeader = CommonReportHeader()
End Sub
--------------------------------------------------

At first this looks a little convoluted, but one advantage is that once you get
it all running, move on to other things, and get stronger with VB; you have the
option of going back and re-coding CommonReportHeader() so that, instead of
getting the value from a global constant, it gets it from a .INI file,  some
parm table in the DB, or even a freestanding text file.

Another advantage is that if someday, for some reason, you want to pull that (or
some other) data into a query you can call the same function.

I kind of like the .INI file approach.   Then, if/when you wind up with common
boilerplate in many reports across many applications, the text only resides in a
single place.  

The downsides of a .INI file solution would be the extra documentation and
(depending on the environment) the prospect of people being able to make
uncontrolled/undocumented changes - whereas with the data residing in a global
in the app, somebody would have to make a new rev of the app in order to change
it.

Especially within the confines of MS Access, I wouldn't agree with "never" when
it comes to globals.   What I would say is that I'd better have a *really* good
reason to use a global instead of passing arguments from routine-to-routine.

My take on this subject comes from "Code Complete" by Steve McConnell/Microsoft
Press.   Personally, I'd recommend that book to anybody anywhere as soon as they
find out they will be writing code.

Put a logo in a table.

Change the recordsource on all reports to reference that table.

or, (not as good), create a subreport with the logo, and
use the sub-report instead of using the logo directly.

or, (not good, but better than what you have), use code in
the report setup to get and display the logo.

It is almost never a good idea to have multiple copies of a logo.

Yes, this is a good job for a 'global variable'.  In this case,
a good job for a global table record 'variable', with a field
which contains the logo.

No not a good job for a global VBA variable. You need a
persistent variable (a file or a database record) in which
to store the data, and there is probably no good reason
to copy the data from the global persistent variable to
a global VBA memory variable.

But if you only have 5 reports, the time it would take to change
the logo's is less than the time you have already spent thinking
about this.

(david)