I’ve got an ASP.NET 4.0 site. In the site there’s a treeview control inside an UpdatePanel.
Keep in mind – when the user first visits the page, no postback has occurred (more on this in a minute).
When the user clicks on nodes in the tree, it triggers a postback. I can set history points as the user is moving through the tree – that’s not a big deal. The history point is the ID of the selected node. (I want to use this to drive other information on the page)
There are two behaviors I’m seeing, and I’m stumped as to how to rectify these:
- First, the history points always seem to point to the current item. If I start on Item A, then click Item B, when I hit the back button, I wind up at Item B for a couple of clicks (as if the history points are all set to the same value). I thought the history should be a running list of the nodes the user clicked…but in this case, it seems like the list is always a collection of history points with the current ID. (If anyone knows how to expose the collection of history points in the scriptmanager, I’d love to hear how)
- Second, and more of a headache, is that when the tree initially loads, there’s no postback. Is there a way to set a history point without an Ajax postback? (I’d like to have a way to preserve the default state for the tree, but right now going to item A from the root, then clicking back takes the user to whatever page they were on before the hit my page)
Has anyone else noticed weird behavior with the ScriptManager’s history points?
I’ve also thought about alternatives – like viewstate, hidden fields, cookies, session variables…but I haven’t had any luck with any of the solutions I’ve tried. Is there a way to get the back button to work without the history points? (I don’t think there is)
To set a history point without a postback, you call
ScriptManager.AddHistoryPoint().I would venture a guess that adding your history points is not the problem, but in the ScriptManager.Navigate, you are not correctly loading the state back, or maybe you are relying on session information that has already been updated to Item B.
One way to see what is in the history state is to give each history entry a name/title that is descriptive enough to identify the state of the page. For testing, you could use a shortened version of the state string hash or just build a string to identify the state of the page and then when you click and hold the back button to view recent browser history, you will see the pages with descriptive names to identify them.
Here’s the MSDN page talking about that: http://msdn.microsoft.com/en-us/library/cc472966.aspx
BTW: Sorry I’m late getting to this question. If you are still having problems, post some code so we can see what you’re doing. I have implemented the history point functionality on pages with the tree control in an update panel on several of my pages.