Change v2000 to v2003 in control source expressions?

  • Thread starter Thread starter Dinosaur
  • Start date Start date
D

Dinosaur

When I was learning, a book on Access 2000 suggested one way of transferring
information from a VBA module to a report was to set a field's control source
to reference a public variable in the module. So, for example, I had "Public
strPrint as String" in a module and then assigned to strPrint the value to be
printed. In the report textbox's control source, I put "=[strPrint]" (less
quotes) and everything worked just fine.

I just installed Access 2003 and this technique no longer works. All the
textboxes show "#Name?". Poring through documentation and several forums for
a few hours, it appears the rules have changed -- a control source can
reference a public function in a module, but not a variable.

Am I interpreting this correctly or is there something else going on
(libraries, using the wrong incense, whatever)?

I realize a workaround would be to write a "get" function for each such
variable or to write to a field directly from the module but, before doing
that, I want to verify it's necessary. I have 13 reports with 10-30 such
variables for each report and it'll take quite a while to do.

Thanks for any help.

Dan Dinosaur
 
Dan:

Well I've never seen that functionality described in A2000 before and on
testing it, it doesn't work there (at least with SP3). If it was
undocumented functionality described in a book, the problem with using
undocumented functionality is that there's no guarantee that it will work
from version to version (it doesn't work in A2K3 either).
 
Thanks, SA, that's what I needed to know -- that a more experienced user says
it definitely wasn't supported, there's nothing I'm overlooking. I work
entirely by myself and the help files are kind of quiet on the subject (but
much more explicit in A2003) so I had to ask someone else.

Since I saw it, or something like it in a book, I used it without knowing it
was unsupported. Looking back and experimenting now, I suspect I generalized
from a book's example that showed a public function as the source --
something like {=Fget()} (where {} are delimiters just for this text note). I
played with it and found that {=Fget() & "hij"} also works.

Having written my share of compilers/interpreters, I automatically thought
that if that kind of expression worked, any expression would work, especially
since a variable is easier than a function to evaluate. The implementors at
that point must have thought the same since {=strPrint} did work (although it
was immediately edited into {=[strPrint]}). (Hey! I've never written anything
with three brace types together like that: "])}". Something good has come out
of this anyway! Gotta look on the positive side.) In Access 2003, the {=
[strPrint]} doesn't work but {=Fget() & "hij"} does. Knowing how compilers
work, the Access2003 had to do extra work to make this restriction.

Sigh! Back to the drawing board.

As for how it worked in Access2000, my help file says "Microsoft Access 2000
(9.0.7.20)". According to Microsoft's Office Update, it was up to date, but
we know how much we can trust that.

It's not at all important but if you're game, I'm curious if you could
replicate it. I just did it again with an ultra minimal report. In a new
database, Create a report in design view. Add one text box in the detail area
with a control source "=[strPrint]" and set its "format" event procedure. All
other properties of the textbox are defaults, (including the name of the
textbox, "Text0"). My entire module backing the report is:

------
Option Compare Database
Option Explicit

Public strPrint As String
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
strPrint = "xyz"
End Sub
-----

Previewing the report on my version of the software shows the "xyz" showing
up as the only contents of the form.

Once again, thanks.

Dan

Dan:

Well I've never seen that functionality described in A2000 before and on
testing it, it doesn't work there (at least with SP3). If it was
undocumented functionality described in a book, the problem with using
undocumented functionality is that there's no guarantee that it will work
from version to version (it doesn't work in A2K3 either).
When I was learning, a book on Access 2000 suggested one way of
transferring
Click to expand...
[quoted text clipped - 24 lines]
Dan Dinosaur
Click to expand...
Click to expand...
 
Back
Top