Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Move code from Refresh method to CustomRefresh()
Message
From
10/09/2018 16:02:35
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
01661889
Message ID:
01661934
Views:
57
>>>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?
>>
>>Sounds like you should have a form method called SetParentID, which is a reasonable name for the task you are performing.
>
>The name is not important (IMO) but your message confirms my approach of having form method calling a method of a textbox is reasonable.

A control calling a form method per se is not unreasonable - esp. if the form mthod can be used across different forms and/or controls.

In that form method accessing the disk might be more problematic, as you cross boundries if your app uses ANY kind of layered approach:
In most of my designs the a biz layer call would be triggered instead of a form call, and that biz layer call would either set records "correct" or fill a memvar/property with the correct ID value, so that GUI layer can remain free of implemetation details of ID setting/reading/record positioning.

Form methods should be targeting common GUI tasks like setting correct RGB values to text elements used as field desriptions, for instance when switching from disabled to enabled.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform