>>The only way I got it to work was
>>oPageRef.parent.activepage=oPageRef.pageorder
>
>Assume I issue your code above from a method and oPageRef is referencing Page3 on a pageframe. Does that mean that the active page is set to the pageframe's PageOrder of Page3 (which may be unknown to us) and Page3 will be activated? Where would you put this code?

This was a wizard-type form, with several scenarios, so it could run with just page1 and page4 being active (simplest case), or with additional pageframes being instantiated in page2 and/or page3, depending on the options chosen on page1. Paths could be varying, and I wanted a simple way to jump back. I created two methods, StorePage and PrevPage. The first would store a reference to the current page into an array property on the form, and the other would just activate the previously stored page. This particular piece of code was in PrevPage. This allowed me to retrace any possible path through pages and pages within pageframes within pages (freely mixed).

>>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.nLastPage]
>
>Why are macro substitution and evaluate unreliable? I've heard that before, but never understood why?

Not unreliable; they work. But they require more care, because any syntax error in the expression evaluated or macro-expanded will not be discovered until runtime. Any line containing & will not be precompiled - it's compiled on the fly at runtime. This is taking time and is generally avoided in tight loops, or in complicated forms. I'm not preaching any purity, I just use them both when I really need them, but each time I check to see if there's an easier way.

>To digress slightly from your reply and address something I posed earlier in the thread, when should you use the Valid as opposed to the Click methods?

For buttons, validation is there just for compatibility's sake, simply because old FP code had valid functions with the buttons, so the conversion code would port the validation into the new object. Other than that, what's the point? The purpose of validation is to check the data before writing them, thus it does make sense for bound controls, or any controls which have a value. What is the value of a commandbutton? It doesn't have one. What does one do with a button? Click it. OK, so common sense would tell me to, if I expected any code to be in the button's methods, look into .click first. For textboxes, I'd check .valid, .interactivechange, .lostfocus - that's the common places for them.