>>>>Labels, for example, do not own ControSource. But refresh :)

>>>I was just thinking of that too. I have Labels that change the Caption when a record moves, and they refresh.

>>But then there must be code doing this. This might be the right place for any work on change of record pointer, do you trace this via refresh?

>There is only one Label and Textbox on this form which are NOT on a container. And the Label does have a code in the Refresh method that changes the Caption. All other controls are on Containers. And since the Containers refresh, all controls on the containers refresh too.
>
>>off topic
>>Have you considered to use textbox instead of label? ReadOnly, no frame and so on could look like a label ... Just RETURN .F. in WHEN, and you have a label that alters text on record change ...
>
>This form is super populated and has tons of code. I prefer not to make any "big" changes so that not to brake something.

You are already braking! Break something to stop braking!
In earnest: Lutz' hint on switching to a textbox is right on topic.

Create it, call it Label_Dynamic and switch all your modifying labels over to that class and cut down on refreshes, esp. those called on whole containers - they don't discriminate and punish all controls...

vfp gives you C++ runtime speeds for dynamic controls changed via changes to .ControlSource, while you are recreating that functionality in vfp code. Going against vfp "flow" and probably even worse than going against DRY to recreate something already done better...