I've found yet another case where code works perfectly well in the same db
run under Access 2002 but fails when run under Access 2010.
I have a continuous subform which calculates a value (vTBA) in the
AfterUpdate event.
This value is then written (in the same procedure) for the user to see in an
unbound control in the sub form footer.
It is simply:
me!TBA = vTBA
me.Refresh
Problem is that it doesn't refresh. The value remains the same.
If I select the 'Refresh All' button in the ribbon, it updates immediately
(but not the 'Refresh' option).
So how can I get 'Refresh All' to work in vba? It doesn't seem appear in the
help file?


--
Bob Darlington
Brisbane

Bob Darlington wrote:


Not sure I can help here, but the refresh menu item is
different from the Refresh method. The menu/ribbon
refreshes the screen and is more closely related to the
Requery method.

The Refresh method causes the form to reload any of its
records that have been modified by another user. It does
not check for new records that have been added by other
users.

Most of the time, when a value in a text box is not
displayed immediately after it's changed, it's because the
form or some other part of Access is too busy to update the
display (updating the display is a lower priority task).

Sometimes using the Repaint method and/or adding one or two
DoEvents statements can force the display to updated or give
the other activities some time to finish.

--
Marsh

"Marshall Barton" <marshbarton (AT) wowway (DOT) com> wrote

Thanks for responding Marsh.
From the help file:
"Using the Refresh method is equivalent to clicking Refresh on the Home tab"
The recordsource is a local temparary table and not subject to data changes
from other sources.
I can use the Requery method, I suppose, but that then entails resetting the
focus back to the edited record each time.
I've tried Repaint, Recalc, Refresh, and DoEvents without any joy.
I've also tried waiting for a full minute to see if it changes.
My application includes 227 screens, and I have used the Refresh method
extensively throughout.
I'm not excited about the prospect of going through all of them if I can
avoid it.

--
Bob Darlington
Brisbane

Bob Darlington wrote:


Yeah, sometimes it seems like Access just forgets or never
noticed that the control's value was changed. Whatever the
reason, it's a tough situation and I've never heard of a
reliable way to get past it.

My attempts to deal it is in this order:
DoEvents
and if that's not adequate, then
Me.Repaint
then
DoEvents
Me.Repaint
then
DoEvents
Me.Repaint
DoEvents

At least for the few times I've run into the problem, that's
been sufficient. OTOH, I've heard of a couple of folks (and
you may be another) that said something more such as Requery
was needed. I think I remember one person that used
minimize and restore.

--
Marsh

Thanks Marshall.
The most frustrating bit is that the same code works in Access 2002.
There is something different in 2010.

--
Bob Darlington
Brisbane
"Marshall Barton" <marshbarton (AT) wowway (DOT) com> wrote

Bob Darlington wrote:


There are a ton if things that are different in A2010. I
suspect that some of the changes make this problem manifest
at different times, but the core problem has been there for
a long, long time.

I just had another idea that maybe adding a couple of
DoEvents BEFORE setting the text box's value, Who knows,
but maybe Access (or Windows) will then be able to finish
whatever higher priority tasks are getting in the way and be
able to deal with the text box correctly??

--
Marsh

"Marshall Barton" <marshbarton (AT) wowway (DOT) com> wrote

Thanks for the reply Marsh.
I've tried all your suggestions without luck.
I might just be lucky, but I've been developing Access applications for a
living since 1994, and this is the first time I've struck this one.
If the program code writes a value to an unbound control, then that control
should be updated immediately (even without a refresh). There is no other
activity happening here.

A couple of additional points from further testing:
1. If the control (Me!TBA) is moved to a row in the continuous subform
(instead of the footer) it updates immediately.
2. The value is being calculated and a debug print will verify the new value
for both the variable and the control.
3. If I insert a MsgBox at the end of the AfterUpdate procedure to indicate
the value of the variable, the control updates immediately - before the
MsgBox is closed. But obviously I don't want to create a msgbox to annoy my
users.

As a workaround, I'm now using Requery and bookmarks, but I still think it
is a bug which should be fixed.

--
Bob Darlington
Brisbane

Bob Darlington wrote:


IMO, a small delay should be the worst noticeable effect.
OTOH, repainting is a pretty low priority task so I guess
it's possible that the problem inevitable under the right
combination of system activities.

Your point 1. is interesting, but I'm not clear about how to
take advantage of it. Maybe putting another text box in the
footer that gets its value (using =TBA) from the detail text
box??

I think your point 3. seems to imply that Access did not
lose track that the text box's value was changed or that it
needs to be repainted. Most likely, the MsgBox serves as a
super long DoEvents that allows Windows or Access to finally
get enough time to catch up.

--
Marsh