Well and good, but it would be nice to have the CurrentPage as a property in the PageEventArgs as well. Why?

Generally, it could provide a way to consolidate PageActivated handling in a single method for all the pages versus implementing PageActivated for each individual WizardPage. I'm not talking about having a huge switch & case statement, although there are cases where that would be preferred to a bunch of individual methods (I suppose). I'm more talking about situations where the data I need is already a property of the WizardPage itself and I could write one generic handler for a PageActivated events.

Specifically, in my wizard, I am collecting data points for a BO and populating it gradually through the pages of the wizard. Because it's fairly complicated, I am also providing RTF instructions along with each step. Each WizardPage has an RTF control that I want to bind to a WizardInstructionsBO, which has only two fields: WizardPageName (key), and InstructionsRTF.

I can't bind the RTF controls on the WizardPages to the primary BO because they are not distinct values in the primary BO. I could have a dozen RTF fields in the primary BO that would be identical for every row, but that seems a waste...

Anyway, having the CurrentPage passed as part of PageEventArgs would make this and similar scenarios easier to handle, and I have to believe this would be an easy change in the framework as well.

Thanks!

I am more than willing to accomodate you on this but I do not see the point.  Let me explain...if you are handling the PageActivated event within the page itself, the current page would just be (Me) or (this).  It would be itself.  If you are handling the PageActivated event of the wizard control, all you need to do is reference the CurrentPage property of the wizard control:

this.WizardControl.Currentpage

Let me know if this does not meet your needs.