>>Secondly, instead of setting ActivePage, try .T48_page_frame1.Page4.activate().
>
>This didn't work for me a couple of weeks ago, when I really needed it. I'm not surprised it didn't work for the pages of a pageframe which was within a currently invisible page of the current pageframe, but it didn't work for the pages of the parent pageframe, either. The only way I got it to work was
>

oPageRef.parent.activepage=oPageRef.pageorder

>and then it worked even for pages in pageframes in pages of pageframes - it all started showing up properly. For a while I thought it might not work if I reordered pages, but I think Hacker's guide mentioned that ActivePage property actually tracks pages by PageOrder, not by order of instantiation.
>
>>Finally, I have a habit to avoid macros, if it's not necessary. In this particular case you can use:
>>loPage=evaluate("thisform.t48_page_frame1."+m.cLastPage)
>>loPage.Activate()
>
>I'd rather not use evaluate() either, if possible. Instead of passing the page's name (which we can't be too sure of, i.e. can anyone be sure the 4th page will be named page4, and that the "page"+trans(i) will give the right name for each page?), I prefer passing the page's number, and then
>

loPage=thisform.t48_page_frame1.pages[m.<b>n</b>LastPage]

>so we don't impose any assumptions as to the page's name (actually, Page1, Page2 etc make sense only while there are not more than four of them). I apply the same thing to grid.columns[n], optiongroup.buttons[n] etc - anywhere where I can get the object reference without involving the names.

The only problem here, what you should know this n, for me it sometimes simpler to use column (page) names instead of number. Besides, I usually give a meangful name to grid columns/pages, so I can easily recognize them, if needed.

But this is just a personal preference :)