Treeview inside an UpdatePanel

The ASP .NET Treeview control is one of the few controls not natively supported by UpdatePanels. Most of the time, this is not a problem – it already includes a bunch of client-side javascript for checking/unchecking the correct nodes, so most of it is client-side anyway, requiring no annoying postbacks.

However, from time to time you absolutely need it to be in an UpdatePanel. In one of my current projects, we have a modal popup (from the AJAX Control Toolkit) with a customized Treeview (customized as in: it includes lots of custom javascript for checking/unchecking the correct nodes when clicked) in it. A bit of server-side code has to be executed to make sure the correct treenodes are checked when the popup is displayed, so we simply fill the treeview with the correct data from the database, check the correct nodes and enable the modalpopupextender from code-behind. No UpdatePanels involved, works like a charm.

After a while, a problem arose: our customized Treeview can grow to be quite big, containing hundreds and hundreds of child nodes. Meaning: since the popup is enabled/disabled in code-behind, the time for it to display became longer and longer. Instead of seeing the popup when clicking a button, the user had to wait 1-2 seconds for it to display. A “minor” annoyance, definitely something you’d want to get rid of.

So we implemented a lazy loading/load on demand technique: show the modalpopup client-side, and execute some javascript after this to make sure the loading & displaying of the Treeview only starts when the modal popup is already on-screen (more on this technique in a future post), thus providing a much smoother user interface. Problem solved? Hardly.

To make this approach work, we use an UpdatePanel around the treeview inside the modal popup, to make sure we can load only this portion of the page on demand… And UpdatePanels & Treeview-controls don’t match. This became painfully obvious when we started to get null-object errors when clicking any treeview-node…

Running through the code in debug obviously didn’t clarify much. The problem with the Treeview and UpdatePanel/ScriptManager lies (ao) in the fact that they both use quite some javascript to enable their functionality. In this case even more so, since our customized Treeview contains quite some extra javascript functions. Apparently, the correct scripts for the Treeview aren’t loaded when you lazy-load a Treeview that’s inside an UpdatePanel. Sigh.

But… surely, the Treeview doesn’t use its own collection of javascript functions for each Treeview on a page, right? That would cause way too much overhead, right? This would mean there’d have to be a collection of javascript-functions, inserted by ASP .NET when placing one or more Treeview controls on a page, which could then be used by any Treeview on this page. Right? What would happen if I were to make sure all javascript functions used by a Treeview were loaded by default? Would this solve my problem?

I gave this approach a try: I placed a dummy customized Treeview control on my page, setting its style to display:none. This should make sure all javascript functions are loaded by default, so other Treeview controls should be able to use them.

… and apparently, this did the trick! 🙂

I’m still not entirely sure if I’m on the right track here when talking about how javascript is inserted by ASP .NET. But what I am sure of is, when using this approach, our customized Treeview works like a charm, inside an UpdatePanel inside an on-demand-loaded modal popup. Hope it helps! 😉