I look at this as if you are the form and I am in a car as the report. You
give me the instruction to drive to the local grocery store. As I am heading
off down the road, you (code in the form) yell at me to make sure I don't
forget to pick up some beer. Since I am down the road already, I might not
hear you. Now, if you were in the backseat of the car (code in the report)
and told me to not forget the beer, I would be sure to hear you.

I would probably get beer anyway but that's another story...

--
Duane Hookom
MS Access MVP
--

"Smit-Dog" wrote in message
...
Thanks Duane.

I did move the code into the report oblject's Report_Open event, and it
worked fine. Just a weird Access anomaly. Can't consistently set the
Caption
property from another form of a Label control that resides on a report
object.

I guess that personally I did expect it to work, and it did, just not if
the
Filter property was set.

"Duane Hookom" wrote:

I would never expect code not contained in a report event to modify the
properties/values of controls in the report in a way that can be
displayed
in the preview. If I want to modify something in my report, I always use
code/functions called in the On Format, On Print, On Page, On
Open,...etc of
the report or its sections.

--
Duane Hookom
MS Access MVP
--

"Smit-Dog" wrote in message
...
So nobody has experienced this weirdness with the Access reporting
rendering
engine?

My current brute force workaround is to programatically open the
report
first in design mode, set the values of labels (had to convert text
boxes
to
label controls in order to set them at design time), save the report,
close
it, then finally open it in preview mode.

It's a hack to be sure, but it's simple (couple of extra lines), and
does
not degrade performance. But it bugs me that this has to be done. My
nickname
for Access is now "Hack-sess".

"Smit-Dog" wrote:

I have a report with a bunch of unbound text box controls. The
report is
opened, and then I explicitly populate a few text boxes with data:

DoCmd.OpenReport "rptSchool", acPreview, , "(GUID=""" & strGUID &
""")"

With Report_rptSchool.Controls
.Item("txtBldgAge").Value = Round(intBuildingAge, 0)
.Item("txtBldgSizeGSF").Value = Format$(lngBuildingSize,
"#,##0")
.Item("txtSiteSize").Value = Round(dblSiteSize, 2)
End With

This works great if the Filter property = "", or if the Filter
property
is
set to a single field criteria during the Report_Open event, i.e.
"(([ConstellationID] in (6)))".

If the Filter property is set to multiple criteria in the
Report_Open
even,
the unbound text boxes are somehow "invisible". Example:
(([ConstellationID]
in (6)) and ([FacilityTypeID] in (3)))

By invisable, I mean that the text box is actually there, and the
value
is
actually set, but for some reason the Access report rendering engine
"blanks"
out the values for these text boxes. I set the foreground and font
colors of
the text boxes to cyan/red respectively, and I can see the text
boxes on
the
report, it's just that the values are invisible. Checking the text
box
value
properties at runtime with the debug window, it does return the
value,
so I
know the value is being set in code. And if the Filter ="", it works
fine,
and if the Filter = (([ConstellationID] in (6))) or Filter =
([FacilityTypeID] in (3)), it works fine. It just when the
Constellation
and
FacilityType are combined in the Filter property.

This is driving me batty. Does anyone have a clue what the Access
report
engine is doing here?

Thanks!!!

- Bill