A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Setting Up & Running Reports
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

"AND" Clause in Filter Makes Unbound Text Boxes "Invisible"



 
 
Thread Tools Display Modes
  #1  
Old August 30th, 2004, 07:03 PM
Smit-Dog
external usenet poster
 
Posts: n/a
Default "AND" Clause in Filter Makes Unbound Text Boxes "Invisible"

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
  #2  
Old September 2nd, 2004, 04:47 PM
Smit-Dog
external usenet poster
 
Posts: n/a
Default

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

  #3  
Old September 2nd, 2004, 05:46 PM
Duane Hookom
external usenet poster
 
Posts: n/a
Default

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



  #4  
Old September 10th, 2004, 08:47 PM
Smit-Dog
external usenet poster
 
Posts: n/a
Default

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




  #5  
Old September 10th, 2004, 09:52 PM
Duane Hookom
external usenet poster
 
Posts: n/a
Default

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






 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 10:25 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.