>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>I have a general question about the following situation. Just to see if anybody thinks it is a good or a bad practice. Or sees any gotchas with this approach.
>>>>>>>>
>>>>>>>>I have a textbox class that shows the value of the ID (unique field) from a lookup (parent) table, based on the PK value in the child table. The code that uses the Seek() the lookup (parent) table and sets the value of the ID (or unique field) is in the Refresh method of this textbox. This approach works. But ... The Refresh of the textbox fires quite often. Any time another window/form is open and then the focus is returned back to this form, the Refresh fires. I would like to reduce the calls to the Refresh field.
>>>>>>>>
>>>>>>>>So, my approach, is to create a custom refresh method (e.g. CustomRefresh), move the code from the Refresh to the CustomRefresh. Then call the textbox CustomRefresh from a method of a form, whenever a record moves. Therefore, the code in CustomRefresh will not be fired unnecessarily often but only when is necessary, when record pointer moves.
>>>>>>>>
>>>>>>>>Does the above seem like a reasonable approach?
>>>>>>>
>>>>>>>I wonder why the refresh happens so often, it looks like a problem that should be resolved on a higher level if possible. Refresh should only happen when you call loForm.Show(), and for the rest only if you call THISFORM.Refresh() on purpose, which should not be needed very often. Refresh is only necessary to call if the data that relates to the controlsource of an object has been changed and needs to be updated on these controls. There is no other purpose for refresh.
>>>>>>>
>>>>>>>Any other call to refresh is problematic. I once inherited a program that called THISFORM.Refresh in the forms Activate() method, a very bad practice, which made debugging any refresh related code impossible, because whenever you have the debugger active and then try to get back to the form, the activate would again call Refresh(). And that for no other purpose than to annoy the programmer.
>>>>>>
>>>>>>Doesn't form Refresh and Refresh of all controls on the form fire when the form goes into focus? And if the previous is true, then any time another form is closed and the focus goes back to the "initial" form, the Refresh fire. Is this correct?
>>>>>
>>>>>
>>>>>According to my knowledge refresh is not fired when the form gets activated. It would be a disaster if that were true.
>>>>
>>>>I did a little test; added strtofile() into the refresh of the textbox. I get tons of calls to this Refresh. Even when I click from one textbox to another (on the same form), the Refresh fires. Disaster :)
>>>
>>>Check in the debugger the trace which methods are actaully calling the refresh. There is indeed a problem that you should investigate, because there is really no reason to call Refresh other than if the textboxes underlying controlsource value has changed and you need to display that on the control. If the values would change all the time (that is the situation where refresh would need to be done), the user would see constantly changing values on the input form, which sounds kind of weird in the first place, making the calling of refresh so often very questionable. My guess is, that someone has scattered THISFORM.Refresh() in many places, because the programmer did not know what refresh is for and there may have been bugs that were never properly resolved. So the refresh may have solved some of those issues, but also making the application slow and difficult to debug.
>>>
>>>In any case it sounds interesting to check which method is calling the refresh. I have lots of situations where the refresh calls queries and I completely rely on the fact that this event is called in an absolutely controlled manner, and not just by coincidence when VFP feels like it. If that works as supposed to, then it is very convenient because you can do a lot of interesting stuff in Refresh.
>>
>>I figured what calls the Refresh. The form has a pageframe (where all controls are). And there is a thisform.Refresh() in the page Activate method. I completely forgot about it. Now I can deal with this.
>>Thank you.
>
>I have seen this solution in some frameworks, it dealt with the problem that pages are only updated as long as they are visible. That is a behavior to save resources when there is a pageframe with a lot of pages, and if you issue THISFORM.Refresh() it would only update the currently visible page. The problem is that it is then up to you to refresh the other pages, which then was done in Activate() because that seemed to be the easiest way to do, but it was not thought well through. Imagine, because of the behavior that should save resources, you are now calling refresh all the time, it is kind of ironic. Also some people tried to put the refresh in the page click event, until they realized that you can activate a page also without clicking on it.
>
>I prefer another solution that is more controlled and directly related to the refresh() method. This also seems to be more logic, because I expect a refresh to also refresh invisible pages (unless there are 100 pages with millions of controls, but that is probably bad design.)
>
>In the Pageframe.Refresh() method put the following Code:
>
>

>LOCAL loPage AS Page
>FOR EACH loPage IN THIS.Pages
>	loPage.Refresh()
>ENDFOR
>

Thank you.