Screen Flashes, Flickers and Form Refreshes

[Valedevargo49]

Hi,


Help! I'm experiencing he exact same issue. I've tried most of the solution offered in this thread, with no success. I think my specific issue may lie in the excessive number of calculated fields in my dataset. Out of about 25 fields on my subform, about 20 are calculated.

I don't have any tab controls on the subform (though other subforms on the parent do), and all of my labels are tied to controls.

I'm on Access 2010 running on Windows 7.

Here's additional background information on the design for the form and my specific issue:

I have a subform in “Continuous Forms” view that sits on a parent form. The subform’s recordset is a query that contains a mixture of calculated fields and fields from a table (though the majority of the fields, by far, are calculated). On the subform, several of the fields have conditional formatting applied.


I have a combo box on the parent form that allows me to go to a specific record on the form (using the “FindFirst” method in the combo box's After Update event) that then filters the subform.


There are more fields in the subform than can be displayed, so there’s a horizontal navigation bar that allows me to scroll left and right to view the fields. Likewise, there’s a vertical scroll bar on the subform that allows be to scroll up and down to view the records.


The issue:


When the form loads or when I use the combo box to go to another record or when I use either the vertical or horizontal scroll bars, all of the records in the subform refresh causing them to “flicker” as if the form is loading for the first time.


This provides for an awful user experience. The records/rows are constantly “flickering” and "reloading" and it’s really annoying!


Is there anything that can be done about this?


Any assistance is GREATLY appreciated!!


Manuel

 

[Simon_MT]

whilst this might not be a solution - if you have a combibox on the parent and using this to slect records the screen is going to have re-render after selection. I work on the basis of the stillness principle.

I have images lots - 25,000 but they are all the same size or on the web in a container <div> with positioning within the container. So the web pages text does not have re-position or wait for the image dimensions to align the remaining information.

So in Access I put the combibox before the data screen so that on the screen rendering the data is already filtered and if users want another selection there is another button going back to the Dialogue box with the combi-box.

Calculated fields are in the Query not on the form or report which the exception of Weighted Averages. This way the calculated can be rendered directly to the screen. Less for the load to do.

Anchoring can also be a nuisance and only use if it has some real benefit. Subforms to elongate height for different screen resolutions.

There are issues with the lack of stillness even in the Navigation Pane and this remains even in Access 2016. Its like Access has Parkinsons. Access certainly get the jitters with jpg images it has only been since 2007 it could handle jpegs in their natural format.

I have also noticed things like screen footer totals not been calculated at times and subforms with Alternative row colours distorting.

I personally think that if can look at behaviour of your screen and reduce the variability and any possible positional movement you may get some improvements. It is a pane in the derriere.

Simon

 

[arnelgp]

can anybody try this, it is supposed to eliminate flicker on the form, insert the code in your form:

Option Compare Database
Option Explicit
#If Win64 Then
Private Declare PtrSafe Function SetLayeredWindowAttributes Lib "user32" (ByVal hwnd As Long, ByVal crKey As LongPtr, ByVal bAlpha As Byte, ByVal dwFlags As Long) As Long
Private Declare PtrSafe Function GetWindowLong Lib "user32" Alias "GetWindowLongA" (ByVal hwnd As LongPtr, ByVal nIndex As Long) As LongPtr
Private Declare PtrSafe Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As LongPtr, ByVal nIndex As Long, ByVal dwNewLong As LongPtr) As LongPtr
Private Declare PtrSafe Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
Private Declare PtrSafe Function SetWindowPos Lib "user32" (ByVal hwnd As LongPtr, ByVal hWndInsertAfter As LongPtr, ByVal x As Long, ByVal y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
#Else
Private Declare Function SetLayeredWindowAttributes Lib "user32" (ByVal hwnd As Long, ByVal crKey As Long, ByVal bAlpha As Byte, ByVal dwFlags As Long) As Long
Private Declare Function GetWindowLong Lib "user32" Alias "GetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Declare Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
Private Declare Function SetWindowPos Lib "user32" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
#End If
Private Type POINTAPI
        x As Long
        y As Long
End Type


Dim a As Single

Private Sub Form_Load()
#If Win64 Then
Dim ret As LongPtr
#Else
Dim ret As Long
#End If
SetWindowPos Me.hwnd, -1, 100, 100, Me.InsideWidth * 0.06, Me.InsideHeight * 0.06, 0
ret = GetWindowLong(Me.hwnd, -20)
ret = ret Or &H80000
SetWindowLong Me.hwnd, -20, ret
SetLayeredWindowAttributes Me.hwnd, vbBlack, 255, &H2

End Sub

 

[isladogs]

can anybody try this, it is supposed to eliminate flicker on the form, insert the code in your form:

One year on and I've been meaning to try this for some time.

Not sure where you got the code from but I'd be happy to post this response if you know the site...

The effect was to cause a flickering form to 'hang' without fully loading until I clicked on the form.
Then it flickered & finished loading

I've removed it!

 

[The_Doc_Man]

And yet I've never seen this on a database that had LOTS of complex forms and that migrated from Ac2003 to Ac2007 to Ac2010 to Ac2013. Well, it flickered a couple of times when I forced more than one repaint to occur in my formatting routines. I had to remove the auto-repaint from the subroutines and put it in-line in the code used for the "Update" function that I had written because the subroutines were called more than once in a given sequence.

When I did that my problem went away. I'm not saying that anyone else is doing this, but if you have a .Refresh, .Repaint, or .Requery in subroutines, you might run the risk of triggering those actions multiple times in a single event routine.

 

[arnelgp]

sorry if it didn't do the magic.


got it from planet-source-code.com.

 

[bomba268]

I am really new to Access, so please don't eat me alive. The form is pretty darn basic with almost no code whatsoever. It's based on a single table (plus a few other tables as lookups), and several people will be using it for data entry purposes (side note: I know the single table will drive many here crazy as it's not proper DB design, but it will work fine in this particular situation and be easier for me to deal with right now).

The main form has 3 tabs, and the flickering occurs primarily when switching between them. It also happens when you open the form originally, but it's not quite as severe. When I remove the theme from the tabs and have a transparent background, the flickering goes away, but I don't really care for the way it looks in general, and the tab labels at the top of the tab page got strangely distorted when I removed the theme anyway. I'd really like to keep the theme, but I really need to get the flicker to go away as well. There is nearly no code right now, and the flicker was there before I added the small amount of code that I did (the code is essentially just 2 buttons to switch between the tabs - one called "next" and the other called "previous"

I've tried a variety of things, including most of the stuff mentioned here, but thus far, nothing works. I need this flickering to stop before I go crazy. Thank you in advance! I'm more than happy to share the file with anyone willing to take a look at it. I'm pretty desperate! Thank you in advance!

 

[ErinB]

I had this same problem - the solution I found was to move all code from the "On Load" function into the "On Open" function. No more flickering!

 

[Sam Summers]

I had the same problem and just fixed it.

I have a form with a subform on it as a continuous form and i had Me.Requery on the On Current event.

I removed that and all is fine now

 

[Abes]

It's been a long time since the last post on this thread so I am wondering whether somebody has come upon a solution for the screen flicker issue. It still persists in Access 2016, or at least it does with me. I have tried all of the above suggestions, without success, and here I am talking about simply clicking on a button to open another form, without any other database processing taking place before the form opens.

 

[Saphirah]

To help you, i would suggest you provide us with more info about your problem. Best would be an example database. But i do think it would be best to create a new issue for that.

I had similar problems in the past, and flickering can have various reasons.
So if you provide us with enough information i am sure we can find a solution!

It's been a long time since the last post on this thread so I am wondering whether somebody has come upon a solution for the screen flicker issue. It still persists in Access 2016, or at least it does with me. I have tried all of the above suggestions, without success, and here I am talking about simply clicking on a button to open another form, without any other database processing taking place before the form opens.

 

[isladogs]

Another cause of flickering that are timer events in either the current form or other running forms hidden in the background.
Surprisingly, that doesn't seem to have been mentioned earlier in this lengthy thread...unless I missed it

 

[Saphirah]

Another cause of flickering that are timer events in either the current form or other running forms hidden in the background.
Surprisingly, that doesn't seem to have been mentioned earlier in this lengthy thread...unless I missed it

In my experience flicker does not occur when using timer events. But it may occur if you refresh data, requery your form or set the focus. And of cause if you do these things in a timer event
Especially the requery is mostly the culprit. You can easily fix that by using Form.Recordset.Requery instead of Form.Requery

 

[isladogs]

In my experience flicker does not occur when using timer events. But it may occur if you refresh data, requery your form or set the focus. And of cause if you do these things in a timer event
Especially the requery is mostly the culprit. You can easily fix that by using Form.Recordset.Requery instead of Form.Requery

Whilst I agree completely that requerying is often the cause, your experience is different to mine regarding timer events.
That includes timer events on hidden forms running in the background where no requery is involved.

In fact, I've just spent a couple of hours working on an app with flickering caused by a timer event in a hidden form which is running some background security checks each time the timer runs.

 

[Saphirah]

Your experience

Whilst I agree completely that requerying is often the cause, your experience is different to mine regarding timer events.
That includes timer events on hidden forms running in the background where no requery is involved.

In fact, I've just spent a couple of hours working on an app with flickering caused by a timer event in a hidden form which is running some background security checks each time the timer runs.

That is interesting. The Timer does not change anything on any forms? No edited queries or updated fields, just pure VBA?
To be honest, i do not understand why the flickering would occur then. Because flicker should only occur if you changed something that is displayed, because access needs to rerender the form.
It also happens when you change the width/height property of any control.

What is even weirder is that the form the timer is running on is invisible. Maybe it is editing a different form? I don't know
Oh Access God, bless us with your wisdom! Why are you functioning like you do?

 

[isladogs]

In this particular case, the timer event is just checking whether any other database or other Office programs are running.
If so, the current app is closed as a security precaution against potential hacking from the external app.

Turning off the timer events solves the flickering but of course that stops the checks being run
Luckily its not a major issue

 

[The_Doc_Man]

An explanation for this timer-related behavior is actually simple.

The more you do in the timer, the worst off you are, because Access runs code synchronously. Events cannot interrupt each other. (Exception: If you call DoEvents, you "give up" the CPU in that event routine until the event queue lets you back in again.) Therefore, if you have events running in the background on that timer and they do something that takes a while, NOTHING ELSE IS RUNNING! It DOES NOT MATTER whether what the timer is doing is potentially visible. Flicker occurs when the screen refresh occurs SLOW enough that you can see its individual steps. So if the timer broke in between steps that update the screen, there is suddenly a pause between those updates, regardless of what the timer does.

You see, your events are actually being run by code in Access that CALLS the events in the manner of a subroutine. (After all, the wizard builds the events as Public Sub Form_xxxx(), doesn't it?) The actual data flow for a Form_Current event is that Access starts up the process of updating the form to match the underlying record. Access does that for you behind the scenes as a subroutine. BUT somewhere in there, Access tests whether you declared a Form_Current event routine. If so, it calls it as a sub. It is NOT interrupted by any other event because... each of them ALSO has to be CALLED by Access when the appropriate condition occurs. And, if it happens that you didn't declare a _Current routine, no matter. Because the Access Current code runs whether you cared or not. (If an event in Access occurs and there is no routine there to be called, does the event occur anyway? In this case, the answer is yes. It occurs silently.)

This digression makes sense if you then realize that Form_Timer is just another sub that gets called under specific non-interrupt circumstances. If your timer does something excessive, all of your other code - and all calls for things like .Refresh, .Repaint, .Requery, .whatever - all of them have to wait for the timer sub to release control back to Access.

The ONLY thing you can write that behaves like an interrupt is an Error Handler routine, because that is triggered by a hardware event called a "trap" which technically DOES cause execution to be halted in favor of the Error Handler code. Everything else is synchronous.

Before anyone asks... yes, it is possible to randomly insert events into the pending event queue - like a timer event or a focus-related event after a VBA change of focus. A timer or a VBA-triggered event would go into the front of the queue. So timers might SEEM like they interrupt something. But no, they're just pushy things that jump first in the waiting line sometimes.

 

[Saphirah]

An explanation for this timer-related behavior is actually simple.

Okay but in my understanding a few DoEvents in the timer code should fix the issue then.
I still do not understand why access is flickering though. To my knowledge access does not need to redraw unless you change something from the form. So even if the code takes longer to run, the screen should not flicker as long as you do not close any forms or do something else UI related.

 

[The_Doc_Man]

The problem isn't that the timer routine is doing the redraw, but that something else would like to do the redraw but can't do it so quickly. The timer is interference for whatever visual effects are involved. And putting DoEvents in a timer routine, one that would be busy enough to have this effect, runs the risk that the deferred timer will not be able to keep up with real time. Because all that a DoEvents would do is to defer the rest of the event code. You start accumulating entries in the event queue. The REAL solution is to minimize what the timer code has to do and NEVER let it do anything directly to the screen if you can possibly help it. The other reasons for flicker probably derive from screen actions that occur more often than you think they did.