Not sure this will help and certainly not sure how far you would have to go with this, but take a look at Help file entry DoEvents. If you are doing some of this animation in time-based VBA code, you might try inserting an activation of DoEvents in your event routines at strategically selected points - to let "other" things happen - including other competing events.
See, if you have more than one event-driven thing going on inside Access, you get caught on a poorly-appreciated fact of life. Events are not threads. They are not independent. Access enqueues these events into a "Pending Event" queue. When events are pending, Access executes the events in the order they were fired, taking each one in turn until the queue is empty. But each event is always queued up to wait its turn. It doesn't really "stop" anything because the events for Access are entirely program events, not true interrupts. For example, a FormLoad event merely means that Access has started (or maybe finished) doing the things required to load a form. Windows has no clue whatsoever that a form has been loaded.
Access events cannot interrupt other Access events because they are REALLY not Windows "things" at all - they are Access concepts. But they LOOK like interrupts and people assume that they ARE interrupts. That's why you need to use something like DoEvents when handling multiple events from multiple forms. Worse yet, because Windows programs DO get certain types of events from Windows itself, people often assume that the same class of event is involved. And this is just not so.
Yet another reason why I am often tempted to defenestrate my Windows systems. But there are too many things that I couldn't run if I did that.
