I have a complex set of ASP user controls (ascx)... which I have wrapped with DNNTabStrip.

These user controls/tabs are sequenced and dependant on previous tab content... there are even controls on each userControl that are dependant on previous data content for their 'items'....

My app logic requires that I support two 'modes' -> one wizard  (yellow brick road) like, and the other is more 'tab' or review like... after a certain 'state' is reached.

I would like NOT to have two different modules to present this complex business object.

I think I have reviewed all avaliable material on the DNNTabStrip rendering rules / features.   However I am unable to locate the DNNTabStripWizard code behind file.. which hopefully will provide me with 'exact' details of managing tab and strip properties...

Right now only way to get my controls to display data is to process Page_Load on each and every included control... think ALL... kinda kills the purpose of using TabStrip...

To put it another way... exactly what is the deligate for Tab Callback, when it is in 'callback' mode...  I will need to test for 'dirty needs saving' BEFORE I can move to next Tab... and init its contents...

thanks for all the good work!

Bob

Thanks Jon.... that was just what I needed.. TabStrip is working perfectly...

Now I am digging through the ClientAPI with Elements examples... (of which the online sample throws a 400 error)...

The tab control proceses the 'page' fine... but when I register a child dropdown for onchange callback.. the entire list of controls are 'empty'... but then you knew that.

Is there a way of having default view_state handling for the child controls of the element during client callback?  My userControl (wrapped by the DNNTab) is comprised of many DropDowns... some of which trigger a dependant dropdown item list to refresh... of course during the DDOnChange event/callback there are no values for any of the included child controls.... sigh!  And yes the number of dropdowns and item counts makes manual registration a real chore for the dependancy of the controls (on route to the database) is seldom simple.  Orginal code simply relied on properties exposing the current selection of these.. and passed null when not set or selected.

Looks like  I might have to wire up some sort of dependancy binding on for both server and client side fo ClientAPI calls?

Thanks for you help

Bob