|
|
Rank: Member
Groups: Member
Joined: 7/17/2009
Posts: 17
|
I know that this subject has been discussed in a number of threads, but I have a rather peculiar situation here that I need to discuss.
I have a Splitter defined on a Masterpage, a TreeView menu in the left SplitterPane and a ContentPlaceHolder in the right SplitterPane. (In reality the setup is more complex than that, but I think this example will server the discussion).
The TreeNode items have the NavigateUrl property pointing to ContentPages.
Now: I open the page in IE (8) and get the initial display. I then move the splitter somewhat before selecting a TreeView menu choice.
When I select the TreeView menu choice the new ContentPage is loaded into the ContentPlaceHolder, and the splitter is repositioned to the initial location (as it were when the page first loaded). As far as I understand it, loading of a content page is (from the browsers point of view) a completely new page. ViewState doesn't survive and neither do other volatile content on the masterpage (such as contents of TextBoxes). So it makes sense that the Splitter position is restored to what is defined in the ascx file of the "new" page.
But...if I instead use a standard LinkButton from the left SplitterPane on the MasterPage with the exact same NavigateUrl, the Splitter position is retained between pages !? How? Why?
So, what is right and what is wrong here? Should the splitter position be remembered between pages? If so, how is that possible, and why doesn't it happen when the NavigateUrl is triggered from a TreeNode?'
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Gunnar wrote:But...if I instead use a standard LinkButton from the left SplitterPane on the MasterPage with the exact same NavigateUrl.... How do you use LinkButton with NavigateUrl?
|
|
Rank: Member
Groups: Member
Joined: 7/17/2009
Posts: 17
|
Sorry, PostBackUrl it was...
TreeNode:
NavigateUrl="~/WebForm1.aspx"
LinkButton:
PostBackUrl="~/WebForm1.aspx"
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
This is normal because you are using cross page post back. The Splitter automatically saves its state information in the form, so when the form is posted back, even though to another page, the status information is still there. As such the splitter is able to automatically retreive and reload its state.
Unfortunately there is no equivalent when you use NavigateUrl because NavigateUrl does not involve a post back at all. No form information is ever posted back to the server at all and they are all discarded. That's why when you use NavigateUrl, all information is lost.
A hybrid solution is to handle the TreeView's ClientSideOnItemClick event. Inside that event you can call __doPostBackWithOptions. This is the same function a LinkButton would call to perform the cross page post back and it should achieve the same result for you.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 7/17/2009
Posts: 17
|
No, __doPostBackWithOptions doesn't seem to make any difference.
Is there any way I can track the Splitter position on the server side and save it in Session state? I've tried to save the SplitterPane width, but that doesn't seem to reflect the real position of the splitter.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Unfortunately no. The only way to retain the information is to post back the form.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 7/17/2009
Posts: 17
|
Yes, I realize that.
But when I do get a postback - how do I see the position of the splitter?
The SplitterPane Width property doesn't seem to reflect the actual width of the pane (and hence the splitter position), so what property should I look at to find the splitter position?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi, A post back should always retain the width correctly. Please see here for a working example: http://demo.essentialobjects.com/Default.aspx?path=Splitter\features\_i9However there is a known issue regarding retaining scrolling position. We are working on that issue. Thanks!
|
|