Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Pageframe Page Activate vs. Click methods
Message
From
10/09/2018 20:32:26
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
01661937
Message ID:
01661946
Views:
65
>>>Hi,
>>>
>>>(If you saw my previous thread about textbox Refresh method, you will understand why I am asking this question).
>>>
>>>I have a fairly complicated form with a Pageframe that has 7 pages. When a user changes from Page to Page, I want enable/disable some controls. And I do all in the Page# Activate method. The problem is that with this approach any time the form goes into focus, all controls on the form fire Refresh method. So, I am thinking of moving the code from Page# Activate method to Page Click method. On the surface I don't see any problems with this approach. But, I am wondering, in which cases would you actually use the Activate Page method? Any practical example?
>>
>>I've seen that sort of thing used for "lazy" loading, or, not doing any computations unless you have to.
>>
>>Suppose you have 2 pages, one that allows navigation through parents, and another that shows details of the children of the currently selected parent.
>>
>>One approach is to recalculate the child page information each time the parent record pointer is moved. That way, when the user clicks on the child page the information is already populated and response appears quick and snappy. The downside is each record pointer move on the parent page takes longer than it otherwise might, making it seem more sluggish.
>>
>>A second approach is to say, hey, I never need to calculate and populate the child page until the user actually wants to look at it i.e. run that code in the .Activate() rather than in Form.Refresh() or similar. That way navigation in the parent form is snappier at the cost of slightly less snappiness when switching to the child page. However, you could argue that the total time to view the children you want to see is the same after selecting the correct Parent, and navigating to the correct Parent in the first place would be quicker.
>>
>>The more computationally expensive it is to render the child page, the more attractive is the second approach.
>
>First, thank you for the example.
>
>Regarding your "second approach". Why not populate the child page on the Child Page Click() instead of the Child Page Activate()? The downside (as I discovered) of Activate method is that it files - unnecessarily - all controls' refresh method on the Page. Whereas, Click() does what the Activate() would do and no downside? Or, am I missing something?
>
>Update: I think I was not saying it correctly. The Activate may not (I have to double check) by itself Refreshes the controls. But (in my case) the call thisform.Refresh() does it.
>
>But the question is still: why use Activate instead of Click()

It just seems more precise to me. Other code could programmatically .Activate() a given page, without that page's .Click() being called or fired.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform