>>>Hi Dmitry,
>>>
>>>Keep the "my" code as light as possible. Controls are refreshed more often than you'd expect.
>>
>>Hi Erik,
>>Thank you for the suggestion. The 'my' code is very light (I think). Basically I needed to implement binding a textbox to a PK value and showing in the Value property the Description field of the parent table. So in every Refresh method, my code Seeks a record in the parent table based on the PK value of the bound cursor. I also store the 'last' PK value to the textbox property and only Seek when this PK value changes.
>>I did the work and tested it over the weekend. So far it does not seem to have any negative effects. But I will try this approach with some other controls of the app. The more controls I apply it to, the better results I will have in the long run.
>
>Or not... the amount of work that the refreshes have to perform will grow, and while on today's machines you may not see any delay or flicker, you'll have an user out there who will. Depending on your framework, the refreshes may happen more frequently than you expect.
>
>In this case, I have a suggestion: create a form property and bind your control to it. Then in the event of the PK change (which you would control anyway) change this value to whatever you want. This way the code to change the value runs only when it needs to, not on every refresh.

My line from above "I also store the 'last' PK value to the textbox property and only Seek when this PK value changes. " indicates that 'my' code in refresh indeed runs only when PK value changes. Also, you assume that I control the event of the PK change but it is not so. User can move the record pointer in many places (which changes the PK value). Another thing is I want this class I created to work in any form and not to have to bind each one to a form property. That is, I want all 'my' code to be in just one place - Refresh method - and that is all.
Thank you for your suggestion.