If no other control causes a post back you should be fine, but in my sample I have a button that actually causes a a post back (that was what the tutorial was trying to demonstrate). So what happened (If I remember correctly) was that you click my button that intentionally causes a post back then the rest of the module stopped working  

---

Michael Washington
http://ADefWebserver.com

A Free Open Source DotNetNuke Help Desk Module

I think you can code the WrapUpdatePanelControl in Page_Load rather than Page_Init provided that all of the controls in the panel are visible at the time the panel in which they reside is wrapped with the UpdatePanel. In the case I first mentioned, my html markup in the .ascx had several controls with Visibility="False" and their visibility was being changed during an asynch postback.  By moving the call to WrapUpdatePanelControl earlier in the cycle into the Init event handler, all was well.

I also believe that Michael may be correct in saying that you could call WrapUpdatePanelControl only on the first Page_Load (outside of an if (!IsPostback) block) PROVIDED that no other control (outside the  UpdatePanel or otherwise registered to force a full postback) causes a full postback. However, in the simple test I tried it appeared that even async postbacks from controls within the dynamically wrapped UpdatedPanel caused the UpdatePanel to be lost and the controls to revert back to doing full postbacks. The module still displayed in this case however. DotNetNuke.Framework.AJAX.RegisterScriptManager () does have to be called on each and every Page_Load event or an error will be thrown.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner