>>>>>>>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.
>>>
>>>Yes, very good point. Other code could call .Activate(). Therefore (I am just talking to myself :)), since I am only activating a page when user want to "go" there, then Click() should do the job just as well.
>>
>>I think it might be possible to use the keyboard to go to the "next" page, .Click() wouldn't fire there either. Fast computer users use keyboard shortcuts/hotkeys etc.
>>
>>If it were up to me I'd put the code in .Activate(), it most closely describes where you want the code to run. However you get to that page, all paths lead to .Activate() so you don't have to worry about exactly how you got there. Putting code in .Click() instead just feels like something that would bite me later on.
>>
>>One major consideration is whether you're already using a framework. If so, in most cases you have to do things the "framework way". But maybe you have freedom (and time) to refactor.
>
>This is why I asked the question so that I can avoid the "bite me later on" thing. What you are saying makes sense.
>And I realized that what I need to do is to change the code in my Activate method and call form.Refresh() only when user actually changed from one page to this page. But if this page Activate fires simply because the form gets focus back, the form.Refresh() should not be called.
>Thank you.

Another option is to add a custom property to a page ("PageX"), named something like .NeedsRefresh, with a logical value. If changes on another page (or anywhere else, for that matter) require a refresh of PageX, it can set PageX.NeedsRefresh = .T.

The code that refreshes PageX has PageX.NeedsRefresh = .F. at its bottom.

PageX.Activate() only calls the refresh code if .NeedsRefresh = .T.