Textbox will not show report variable value

[brian]

I have an application developed in Access 2000 that does not work on a
machine running Access 2003. This application commonly uses the
report's PageHeader_Format to set a public variable, which is
referenced in a header textbox using =[variableName]. For example, one
report module contains:

Public rptTrial

Private Sub PageHeader_Format(...)
rptTrial = 1
End Sub

A textbox in the header has a Control Source of: =[rptTrial]

When I run the report, the textbox shows "#Name?". If I change the
=[rptTrial] to =[rptTrialX] and run the report, I am prompted for a
parameter value. Therefore, I know Access understands that rptTrial is
defined, but for some reason is not using its value.

I thought perhaps Access had changed between 2000 and 2003, but I have
2 laptops that are running the identical version of Access 2003
(11.6566.6568 SP2) and the same database file -- one works and the
other doesn't. The one that works is running XP Professional 2002 SP2
and the one that doesn't work is running XP MediaCenter 2002 SP2.

 

[Marshall Barton]

I have an application developed in Access 2000 that does not work on a
machine running Access 2003. This application commonly uses the
report's PageHeader_Format to set a public variable, which is
referenced in a header textbox using =[variableName]. For example, one
report module contains:

Public rptTrial

Private Sub PageHeader_Format(...)
rptTrial = 1
End Sub

A textbox in the header has a Control Source of: =[rptTrial]

When I run the report, the textbox shows "#Name?". If I change the
=[rptTrial] to =[rptTrialX] and run the report, I am prompted for a
parameter value. Therefore, I know Access understands that rptTrial is
defined, but for some reason is not using its value.

I thought perhaps Access had changed between 2000 and 2003, but I have
2 laptops that are running the identical version of Access 2003
(11.6566.6568 SP2) and the same database file -- one works and the
other doesn't. The one that works is running XP Professional 2002 SP2
and the one that doesn't work is running XP MediaCenter 2002 SP2.

It's strange that it works in one place and not another.
However, I think you are going about it in a roundabout way.
I suggest that you scrap the variable, remove the text box
expression and set the text box directly in the code:

Private Sub PageHeader_Format(...)
Me.txtrptTrial = 1
End Sub

 

[brian]

I agree that the code could be improved, but all the reports in this
application use this technique.

I added a function to the report to return the variable value:

Public Function GetRptTrial( )
GetRptTrial = rptTrial
End Function

When I change the textbox Control Source from "=[rptTrial]" to
"=GetRptTrial( )", the correct value shows in the report.

This isn't a solution since it would still require changing all of the
reports.
Any idea why GetRptTrial( ) works but using "rptTrial" directly
doesn't work on this one computer?

Thanks, Brian

 

[Marshall Barton]

I agree that the code could be improved, but all the reports in this
application use this technique.

I added a function to the report to return the variable value:

Public Function GetRptTrial( )
GetRptTrial = rptTrial
End Function

When I change the textbox Control Source from "=[rptTrial]" to
"=GetRptTrial( )", the correct value shows in the report.

This isn't a solution since it would still require changing all of the
reports.
Any idea why GetRptTrial( ) works but using "rptTrial" directly
doesn't work on this one computer?

Ahh, sorry, but I missed the part about using the public
variable in a control source expression. The reason that
won't work is because VBA variables are only available in
VBA procedures, If you insist on using Public variables to
communicate between procedures, then you will have to use a
public function in a standard module. Public functions in a
standard module are the only VBA items that are available
throughout Access.

The reason you thought you would need a function in every
report is because form/report modules are class modules.
Public procedures in a class module are methods of the class
and class methods are strange things until the class has
been instantiated. In other words, don't mess with them
unless you have a decent understanding of classes.

Bottom line, move your public function to the same module as
the public variable and you should be off and running, at
least for a little while.

An important downside to using global variables is that any
unhandled error anywhere in your application will reset your
project and the public variables will be cleared. This can
be very disconcerting when debugging code, but as long as
you have error handling in **every** procedure in your
application, it should be ok for users.

Another downside is that, for numerous reasons, their use is
a poor programming practice. OTOH, some situations are
difficult to deal with without something along the lines of
global variables.

 

[brian]

I could understand if [=rptTrial] never worked or if it worked in
Access 2000, but not in Access 2003. What baffles me is why it works
in both Access 2000 and 2003, but not on a laptop running XP
MediaCenter.

Thanks, Brian

 

[Marshall Barton]

I could understand if [=rptTrial] never worked or if it worked in
Access 2000, but not in Access 2003. What baffles me is why it works
in both Access 2000 and 2003, but not on a laptop running XP
MediaCenter.

Even though I never used A2K, I feel certain that it did not
work in any version unless rptTrial was a public function in
a standard module, but even then the syntax would have to be
=rptTrial()

Or maybe you had a text box named rptTrial with some code in
the report that set its value. But that would mean that you
had two text boxes with the same value which wouldn't make
much sense.

If rptTrial was a public variable in the report's module, it
might have worked even though the proper syntax would have
been =Report.rptTrial