I had an application today with lots of flickering on a form containing two subforms in continuous mode.

When I first load the main form it flickers a little bit, sometimes longer than others (seemingly depending on where my mouse is sitting). Often moving the mouse off of the subforms if it happens to be over them makes the flickering stop and the forms load faster.

Another issue with the flickering was causing very slow form resizing response. As I tried to drag the sizing border of the form, it would seem it was continually redisplaying the form with every pixel and it would flash and move pixel by pixel until it reached my new mouse position. Very unusable really.

Here are some issues I’ve solved with flickering forms in the past:

1. Remove user defined functions or time / resource intensive functions from these areas:
   • Field bindings. If you have user defined functions or things that do database lookups (using the D-functions like DCount, DLookup, etc.) in a field in a continuous form consider other ways to get that data into the field. The best way I’ve found is to create a subquery with the information and join it in to the form datasource. Note that doing this may also require additional work to keep the query editable if you need it to be. Using grouping functions directly in a query will make it uneditable. But, you can create another query and make sure it can join to the primary key of the main query. This will allow you to keep your query editable and this is much faster for form painting.
   • Form section OnPaint events. If you use time consuming functions here this will also have a big impact on the speed of rendering for your form.
   • Conditional Formatting. Using expensive functions in Conditional Formatting will also cause major flickering in continuous subforms. Try to make sure your functions just use straight VBA system functions (but fast ones, not the D-type functions like DLookup, DCount, DAvg, etc.) And even if you are using a fast user defined function, this will usually be super slow in form rendering terms.
2. Event code that does lots of requerying / recalculating of the form. If you need to run code that does a lot of background work and updates several fields or multiple rows, make sure to try to encapsulate that code in Application.Echo False / Application.Echo True groups. Application.Echo False turns off all (well really most) user display feedback until you use Application.Echo True. Turning off screen updating will make your code run much faster if Acccess isn’t trying to update the form for every field update your code does.
3. Hide controls that do lots of updating until you need them to be shown. In the particular form I was just working on, I hid the subform controls when the form lost focus (or was deactivated) and then I showed them again when the form activated again. In order to hide the control, you need to make sure it does not have focus. You can do this by referencing another control on the main form and using the SetFocus method. Say on a button or something. If you don’t have a control with which you can do that, consider adding a close button or something so that you have a control to set focus to.
4. And alternaive to hiding the controls is to make calculated controls and continuous subforms unbound until you are done setting up the main form. Make sure the form is saved with these controls unbound, then bind them to the forms / reports / calculations you need right before you need to display them in runtime code. Unbind them when you know you are about to experience lag such as in the form Resize event.

I hope this helps you. Let me know if you have anything I should add to my list.