Partial Solution.
By removing the vertical scroll bar from one subform and using navigation buttons in its place stops any flickering anywhere when using the scroll bar on the second sub form.
This would suggest that somehow Microsoft have got a problem in the design of their vertical scroll bars if using one causes a flicker in the other.

Without seeing it in action in your database I can't be sure, however, I do get a slight flicker in the same manner using even a single continuous form. If I use the slider, the detail rows move smoothly up and down but clicking the arrows at the top and bottom create a slight flicker in Access itself.

Only a guess based upon my experiences of getting rid of flickers: The arrows are tied to the window and the slider is tied to the section. Even though it appears as a single control, the arrows seem to fire a different mechanism than the slider. Like the arrows are redrawing the page and the slider is only redrawing the section. As a side note: In my case, if I actually grab the part of the slider and move it, no flicker, but if I click the slider bar outside of the active slider section, it gives the same flicker as it is moving several "pages" instead of pulling up an already queued next row.

The only way I can think of to get around this effect would be to turn off scrollbars completely and create a custom solution with controls and vba. I've never done it specifically but it would involve some of the Recordset and RecordsetClone techniques Richard has shown such as in the Fitness series where he shows his bounce function to move through a continuous form with little to no flicker.

You're definitely not imagining it. There have been other reports of flickering and redraw problems with continuous forms in Access, including cases where the behavior changes depending on how you scroll. In at least one publicly reported case, the problem could even be reproduced using Microsoft's Northwind Developer Edition, so it's not necessarily something wrong with your database or form design.

Microsoft has also acknowledged and fixed a more recent, separate continuous-form redraw issue. I don't think that particular bug is the same one you're seeing, especially since you've reproduced yours in both Access 2010 and Access 2024, but it does reinforce that Access has had issues in this general area of form painting and scrolling.

Based on your testing, I'd say your workaround is probably the most practical solution for now. If removing one of the native vertical scrollbars and replacing it with navigation buttons eliminates the flicker, I'd go with that. I wouldn't spend much more time chasing Echo, Painting, Tab Stops, or record source changes if you've already eliminated those possibilities.

For what it's worth, Microsoft is aware of continuous-form redraw and flickering issues in Access and has recently fixed at least one related problem. I can't say that your exact scrollbar issue is the same bug, but this general class of problem is definitely on their radar.

Unfortunately I'm experiencing the problem again on the same main form. With the two subforms I scrapped the vertical scrolling and switched to form navigation which I thought had solved the problem until I entered the third subform.
The third subform contains a number of option groups laid out in vertical frames with each toggle representing a numeric value similar to the numeric keys on the right of a QWERTY keyboard.
When the user makes selections from the third subform, a financial value is automatically updated on the second subform.
When this is done the first subform, now minus the vertical scrolling goes berserk with flickering.
I will be spending today trying to resolve this new found flicker!

That sounds more like an update issue that I've seen happen with continuous forms. When you try to programmatically update a value in a continuous form Access will sometimes struggle to figure out which record you are working with, especially when working from outside that form.

I've had luck with placing the values that I want to edit in fields in the header or footer of that form and then setting the control source of the fields in the rows equal to those header/footer fields. Then, when the field gets edited from outside, it automatically updates the row for the current record. Likewise, the on current event sets the value in those fields to the current row so they are ready for editing if necessary, or if the value is only edited from the 3rd subform, then those fields in the header/footer can be made not visible, or if you're not using the header or footer, you can place the fields in one or the other and set that section to not visible.

Other than that, the only other way to get the values in that I can think of would be doing everything in code then using VBA recordsets to update the record then requery the current row. This method might be cleaner but then you have to watch for the error of Access thinking 2 users are editing the same record.

Thanks. I'll look at that, but sometimes there are four or five records in the second subform that will need to updated at the same time. This is achieved with a do until loop . That has no bearing on the flicker though but I'll certainly experiment with your solution.

Could this flicker be caused by the complexity of form operations in the subforms (e.g. calculated fields, domain aggregate functions, etc.) and/or simply the speed of the computer?  I've seen many bizarre form glitches in Access over the years, so I wouldn't be surprised if this were (mostly) Microsoft's doing.

Yes, form complexity can definitely make flickering more noticeable. Calculated controls, domain aggregate functions, requeries, and updating several records in a loop all give Access more work to do while it is trying to repaint continuous forms.

One other big culprit is conditional formatting. Access has to evaluate and draw that formatting separately for each visible control on each row, and it can be particularly bad with continuous forms. If any of these subforms use conditional formatting, try temporarily removing all of it and see whether the flickering improves.

The speed of the computer can affect how obvious the problem appears, but I don't think this is simply a slow-PC issue. The fact that changing the scrolling/navigation behavior changes the result points strongly to Access's form-painting behavior.

Guys I have the solution for my problem. May work in other scenarios.
Because of the number of forms I have I give the names numerical values.
That way I can keep track of where they fit in.
In this instance the parent form is FD1. The subforms are f2o1B,  f2o1D and the numeric keyboard subform f2o13SP.
f2013SP was providing the financial value update to f2o1D. In doing so when I ran the Requery the flickering occurred principally in f2o1B and in text boxes on the main form FD1.
I was using "FD1.f2o1D.Form.Requery"
By changing that to "FD1.f2o1D.Form.Recordset.Requery" the problem was solved.
By inserting "Recordset.Requery" the flicker has gone.
I'd like to claim credit for this but I have to admit that the solution came from AI
Hope this helps others.

Nice. I covered that three years ago: Requery in Place

:)

I guessed you might have but I didn't know where to look.

Yeah, that's always the problem, and it's one of my dilemmas as a video creator. I try to come up with titles based on what people would actually search for. If someone goes to YouTube or Google and types "my Access form is flickering," I need to have at least some of those keywords in the title or description.

I make videos to solve problems, but I don't always think of every possible phrase someone might use to describe that problem. I certainly didn't three years ago when I made that video. Lately I've tried to be more aware of it, but sometimes just knowing how to ask the question is the first step toward solving it.

That's also why I tell people that, even if they plan to use AI to program or build a database, they'll get much better answers if they understand the terminology themselves. It's like doing research at a library. It helps tremendously if you know the vocabulary for the subject you're researching instead of going in blind.

Needless to say, you'll be seeing a video coming out one of these days soon that includes "Microsoft Access form flicker" in it, lol. I just did a search on Google, and no videos come up. LOL

Pleased that I have played a small part in it.
Whilst the main flicker issue has been solved, the vertical scroll top and bottom arrow issue remains, just a case of teaching people to use the slider, but at least the work around on that is choosing the navigation buttons.
Look forward to the video. LLAP.

How about adding a couple of buttons for Page Up and Page Down? That gives users an obvious alternative to the scrollbar arrows, without having to rely on them remembering to drag the slider.

You can use the form's RecordsetClone to move approximately one screenful of records at a time, then synchronize the form to that record. It is not quite the same as the native scrollbar's page movement, but for a continuous subform it should be close enough and avoids poking the part of Access that seems to trigger the redraw problem.

Or you could even >gasp< use the SendKeys command.

And yes, this whole thread has definitely earned its place on my future "Microsoft Access form flicker" video list. LLAP.