Can I read the value of a textbox control on a report?

[MLH]

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

[Ken Snell]

Because a report is "built" sequentially, it all depends upon where the
textbox is located and what its control source is -- assuming that we're
talking about code within the report. So, it can be unreliable depending
upon when and where you're trying to read it.

You'll likely have better results if you read the value of the field to
which the textbox is bound.
--

Ken Snell
<MS ACCESS MVP>

"MLH" <CR**@NorthState.net> wrote in message
news:gn********************************@4ax.com...

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

[MLH]

On Wed, 4 Jan 2006 18:55:16 -0500, "Ken Snell"
<kt***********@ncoomcastt.renaetl> wrote:

Because a report is "built" sequentially, it all depends upon where the
textbox is located and what its control source is -- assuming that we're
talking about code within the report. So, it can be unreliable depending
upon when and where you're trying to read it.

You'll likely have better results if you read the value of the field to
which the textbox is bound.

Sounds like a plan to me. What syntax do I use to do exactly that?
Obviously, not Me!BlahBlahBlah.

[MLH]

BTW, my apologies for my system date setting of 1/17/06. Have
corrected now that I've noticed it.

[Ken Snell]

Me.FieldName

--

Ken Snell
<MS ACCESS MVP>

"MLH" <CR**@NorthState.net> wrote in message
news:t9********************************@4ax.com...

On Wed, 4 Jan 2006 18:55:16 -0500, "Ken Snell"
<kt***********@ncoomcastt.renaetl> wrote:

Because a report is "built" sequentially, it all depends upon where the
textbox is located and what its control source is -- assuming that we're
talking about code within the report. So, it can be unreliable depending
upon when and where you're trying to read it.

You'll likely have better results if you read the value of the field to
which the textbox is bound.

Sounds like a plan to me. What syntax do I use to do exactly that?
Obviously, not Me!BlahBlahBlah.

[Lyle Fairfield]

MLH <CR**@NorthState.net> wrote in
news:gn********************************@4ax.com:

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

A common way of hiding zero entries is described in help files:

***
Custom Formats
Custom number formats can have one to four sections with semicolons (;)
as the list separator. Each section contains the format specification for
a different type of number.

Section Description
First The format for positive numbers.
Second The format for negative numbers.
Third The format for zero values.
Fourth The format for Null values.
For example, you could use the following custom Currency format:

$#,##0.00[Green];($#,##0.00)[Red];"Zero";"Null"
***

To hide zero we might specifiy

$#,##0.00[Green];($#,##0.00)[Red];"";""

This might be simpler, perhaps even safer then setting the visiblity of
the textbox in code.
--
Lyle Fairfield

[Lyle Fairfield]

In Google my response seems to be a response to Ken Snell's second
contribution to this thread. Actually it's a direct reponse to MLH's
original post, which doesn't show in Google.

[Steve Jorgensen]

MLH wrote:

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

From experience, I can tell you that it is common and reliable to read
text box values in Format events on reports. You can safely access the
value of any control in the section/instance being formatted, or in the
header or footer of any section it is contained within. You can read
footer control values even though the footer will be printed after the
section/instance being formatted because the control's value has already
been determined, even though the formatting to display it might not be.

[MLH]

On Wed, 4 Jan 2006 20:28:51 -0500, "Ken Snell"
<kt***********@ncoomcastt.renaetl> wrote:

Me.FieldName

Thx much, Ken.

[MLH]

From experience, I can tell you that it is common and reliable to read
text box values in Format events on reports. You can safely access the
value of any control in the section/instance being formatted, or in the
header or footer of any section it is contained within. You can read
footer control values even though the footer will be printed after the
section/instance being formatted because the control's value has already
been determined, even though the formatting to display it might not be.

Thx Steve. I'm glad to hear someone confirm this. I make assumptions
that are wrong all the time. I'd done a fair amount of testing on this
topic, but I hadn't convinced myself that was entirely reliable. Thx
for helping out.

[paii, Ron]

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:Np******************************@comcast.com. ..

MLH wrote:

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

From experience, I can tell you that it is common and reliable to read
text box values in Format events on reports. You can safely access the
value of any control in the section/instance being formatted, or in the
header or footer of any section it is contained within. You can read
footer control values even though the footer will be printed after the
section/instance being formatted because the control's value has already
been determined, even though the formatting to display it might not be.

Does the "On Format" event fire each time the page is viewed? I would think
you could have a problem if the user paged up and down causing repeated
updates from the control.

[Steve Jorgensen]

paii, Ron wrote:

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:Np******************************@comcast.com. ..

MLH wrote:

I use A97. I've gotten used to reading values from textbox controls
on forms, I've come to rely on it pretty heavily. My habit spills over
into reports. I'm uncertain whether I can reliably read the values
in textbox controls on reports during the OnFormat event code
the same way I've been doing so in forms.

I have a report I call the 402 report and on it is a LaborCost
textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm getting
what I expect. Who knows about this and feels comfortable
commenting about the topic: Thx.

From experience, I can tell you that it is common and reliable to read
text box values in Format events on reports. You can safely access the
value of any control in the section/instance being formatted, or in the
header or footer of any section it is contained within. You can read
footer control values even though the footer will be printed after the
section/instance being formatted because the control's value has already
been determined, even though the formatting to display it might not be.

Does the "On Format" event fire each time the page is viewed? I would think
you could have a problem if the user paged up and down causing repeated
updates from the control.

It is not predictable when Format will fire, how many times, or in what
order. It's OK though, so long as your code does not do anything that
should care. If you need a counter, for instance, use a running sum
contol with a Control Source of =1 rather than using a counter in code
because accuracy of the the running sum will be maintaned for us by Access.

[Bob Quintal]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:ir********************@comcast.com:

paii, Ron wrote:

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:Np******************************@comcast.com. ..

MLH wrote:

I use A97. I've gotten used to reading values from textbox
controls on forms, I've come to rely on it pretty heavily.
My habit spills over into reports. I'm uncertain whether I
can reliably read the values in textbox controls on reports
during the OnFormat event code the same way I've been doing
so in forms.

I have a report I call the 402 report and on it is a
LaborCost textbox. I use a line of code something like this

If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True

in an attempt to read the control's value. I'm not sure I'm
getting what I expect. Who knows about this and feels
comfortable commenting about the topic: Thx.

From experience, I can tell you that it is common and
reliable to read
text box values in Format events on reports. You can safely
access the value of any control in the section/instance being
formatted, or in the header or footer of any section it is
contained within. You can read footer control values even
though the footer will be printed after the section/instance
being formatted because the control's value has already been
determined, even though the formatting to display it might
not be.

Does the "On Format" event fire each time the page is viewed?
I would think you could have a problem if the user paged up
and down causing repeated updates from the control.

It is not predictable when Format will fire, how many times,
or in what order. It's OK though, so long as your code does
not do anything that should care. If you need a counter, for
instance, use a running sum contol with a Control Source of =1
rather than using a counter in code because accuracy of the
the running sum will be maintaned for us by Access.

The On Retreat event fires when paging up, and I've used it
successfully to maintain counter accuracy.

--
Bob Quintal

PA is y I've altered my email address.

[Steve Jorgensen]

Bob Quintal wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:ir********************@comcast.com:

paii, Ron wrote:

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:Np******************************@comcast.c om...
MLH wrote:
>I use A97. I've gotten used to reading values from textbox
>controls on forms, I've come to rely on it pretty heavily.
>My habit spills over into reports. I'm uncertain whether I
>can reliably read the values in textbox controls on reports
>during the OnFormat event code the same way I've been doing
>so in forms.
>
>I have a report I call the 402 report and on it is a
>LaborCost textbox. I use a line of code something like this
>
>If txtLaborCost > 0 Then Me!txtLaborCost.Visible = True
>
>in an attempt to read the control's value. I'm not sure I'm
>getting what I expect. Who knows about this and feels
>comfortable commenting about the topic: Thx.

From experience, I can tell you that it is common and
reliable to read
text box values in Format events on reports. You can safely
access the value of any control in the section/instance being
formatted, or in the header or footer of any section it is
contained within. You can read footer control values even
though the footer will be printed after the section/instance
being formatted because the control's value has already been
determined, even though the formatting to display it might
not be.
Does the "On Format" event fire each time the page is viewed?
I would think you could have a problem if the user paged up
and down causing repeated updates from the control.

It is not predictable when Format will fire, how many times,
or in what order. It's OK though, so long as your code does
not do anything that should care. If you need a counter, for
instance, use a running sum contol with a Control Source of =1
rather than using a counter in code because accuracy of the
the running sum will be maintaned for us by Access.

The On Retreat event fires when paging up, and I've used it
successfully to maintain counter accuracy.

Sure, but why do that? It's hard to know that you've covered all the
cases correctly, dealt with what happens whenyou print from preview,
etc. It's much easeir to make code that doesn't need to keep track of
the order of events than to track of the order accurately.

[MLH]

Shouldn't be a prob for me. All I'm doing
is setting visible property on a textbox.
Paging through records - some are shown,
some are not. Just depends on the value
in the control.