>>The significance lies in that [snip], until Activate fires, the _Screen.ActiveForm is still the calling form. Therefore, I can place code in the Show, Load or Init of the child form to retrieve information from the calling form using _screen.activeform.whatever. Which I do extensively.
>
>I just re-read your post, and boy was I glad! This point which you made is about to solve a MAJOR problem I was having, figuring out how to do exactly that, get information from the calling form in the called form.
>
>Boy, the event firing sequence sure gets ugly when you've got one form calling another, though. My problems today have stemmed from the fact that the two forms events overlapped as the one called the other then shut itself down. The called form depended on a view being open, or opening it. Between the called form checking whether the view was already open (it was by the calling form), and trying to requery it, the calling form closed the veiw as it unloaded!
>
>Boy do I have a headache!
>
>Cheers,
>Rich.

You might want to get that issue (March) of FPA then. Yes I did notice you left out Activate from your list. I just thought it was an oversight, since the list is so long.

What I have in my base form class is a method that I can call from the Load, Init or Show to retrieve information from the _screen.activeform. This solved a lot of issues I had when using private datasessions almost exclusively.