Hi,
I don't know what can be the exact problem, but a *possible* ugly patch if
to freeze the screen moment before the multiple redraw occur, and unfreeze
the screen later.
It is ugly because the screen will be freeze, which MAY lead the end user
that the PC freeze, is anything turns wrong. And that is only a
possibility that is solves the problem in any respect, since you have to
insert VBA code at two critical places, none of them being clearly
identified.
So, technically, to freeze the painting in a window, you can declare a
reference to the API function LockWindowUpdate (in a standard module):
Public Declare Function LockWindowUpdate Lib "user32" (ByVal hwndLock As
Long) As Long
and then, to lock, freeze, the screen updates for the whole Access
Application:
LockWindowUpdate Application.hWndAccessApp
and to unlock it,
LockWindowUpdate 0
Generally, you heavily error-trap any error between these lines of code,
to unfreeze the window if an error occur (so the end-user won't think your
application is frozen).
Now, where do you type the two said lines of VBA code? if possible, for
the first one, if the sequence of event is generated by your code, do it
just before your code actually fires the sequence. If the sequence is
driven by the end user, try the LostFocus of the form loosing it, or the
GotGocus for the form getting the focus.
As for the second line of code, since I am lost about what really occur in
your case, I would try at the end of the onCurrent event procedure
handler, as example.
Again, that is ugly and only a possibility that if really fix your
problem. Would be better to exactly find the problem itself, such as
debugging in a step by step mode to see exactly what code is executed, if
any, that causes all this unwanted animation.
Hoping it may help,
Vanderghast, Access MVP