Proper use of global variables for reports

[Brent Ritchie]

Hello all,

I just got my first job in the IT field as a junior programmer. Right
now I am working on my first assignment. It's not the best assignment in the
world, but it's something I have thought about. My assignment is:

Change all logos on reports in some Access 2000 Database to some other
value.

Each Logo is really just a label with the same text but it is displayed
differently depending on the report. It's not that I don't know how to do
this but I was wondering if this is a good job for a global variable?

What I want to do is declare a global variable, and then any form that
has to display the logo refrences that variable. I think it would be ok, but
many of my teachers have told me not to ever use them. Do you think it's a
good idea to run by my boss or should I just shut up and do it the manual
way?

Thanks,
Brent

[Anton]

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

[(PeteCresswell)]

Per Brent Ritchie:

What I want to do is declare a global variable, and then any form that
has to display the logo refrences that variable. I think it would be ok, but
many of my teachers have told me not to ever use them. Do you think it's a
good idea to run by my boss or should I just shut up and do it the manual
way?

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.
--
PeteCresswell

[david epsom dot com dot au]

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)

"Brent Ritchie" <br**********@personainternet.com> wrote in message
news:sO******************@news20.bellglobal.com...

Hello all,

I just got my first job in the IT field as a junior programmer. Right
now I am working on my first assignment. It's not the best assignment in
the world, but it's something I have thought about. My assignment is:

Change all logos on reports in some Access 2000 Database to some other
value.

Each Logo is really just a label with the same text but it is displayed
differently depending on the report. It's not that I don't know how to do
this but I was wondering if this is a good job for a global variable?

What I want to do is declare a global variable, and then any form that
has to display the logo refrences that variable. I think it would be ok,
but many of my teachers have told me not to ever use them. Do you think
it's a good idea to run by my boss or should I just shut up and do it the
manual way?

Thanks,
Brent