This is actually a pretty serious one... I use WebSplitter extensively for layout, and WebDataTree extensively for data. I have spent much of my night building divs and getting rid of the WebSplitters to work around this bug.
First, I am using build 11.1.20111.2064. This bug appears to have been introduced in this build.
The screenshot below contains 6 WebDataTrees. The top 3 are in a WebSplitter. They have different server-side events connected to them, and the AutoPostbackFlags match the server-side events.
In this screenshot, I have just gone through each tree and clicked a child node. Note that the trees in the WebSplitter do not fire the NodeClick event. (They do trigger a postback, but the NodeClick event does not execute).
Since a SR has just been released (which introduced this bug), I realize a code update is probably unrealistic. However, I need a workaround as soon as possible on this one. Even if it's just some javascript I can inject.
Here is the sourcecode for the sample page you see above:
Hello Rob,
Thank you for reporting this.
There was another issue fixed in the latest SR which introduces this behavior.
This will be reported as development issue and will be fixed in the next SR.
As temporary solution I recommend you registering the WebDataTree (WebDataMenu) as Control that requires postback handling
http://msdn.microsoft.com/en-us/library/system.web.ui.page.registerrequiresraiseevent.aspx
Let me know about the results.
Hope hearing from you.
Ok, in the sample page above, I modified the Page Load event as follows:
Protected Sub Page_Load(sender As Object, e As System.EventArgs) Handles Me.Load Response.Cache.SetCacheability(HttpCacheability.NoCache) RegisterRequiresRaiseEvent(WebDataTree1) If Not IsPostBack Then BindTree(WebDataTree1) BindTree(WebDataTree2) BindTree(WebDataTree3) BindTree(WebDataTree4) BindTree(WebDataTree5) BindTree(WebDataTree6) End If End Sub
The result is an error on intial page load (no opportunity to get to a postback)
Object reference not set to an instance of an object. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [NullReferenceException: Object reference not set to an instance of an object.] Infragistics.Web.UI.NavigationControls.WebDataTree.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String postArgs) +20 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +13 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +5563
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[NullReferenceException: Object reference not set to an instance of an object.] Infragistics.Web.UI.NavigationControls.WebDataTree.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String postArgs) +20 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +13 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +36 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +5563
I did a little digging, and based on what I have read, RegisterRequiresRaiseEvent may not work exactly the way we hope. It will actually interfere with all other controls that attempt to postback, so it is only useful if the target control is the only control on the page.
I am not sure this is quite the silver bullet we are hoping for.
I really hope that this issue doesn't wait for the next SR. This issue limits the usefulness of the WebSplitter, and I am not prepared to rebuild my entire site to remove the WebSplitter to accommodate bugs for a period of months, only to re-implement the WebSplitter again months from now. Unless we can find a workaround, I will have to abandon the WebSplitter... and to be really honest, it'll damage my trust.
I really appreciate your help, and your advocating with the devs. I understand that not all of the decisions are within your power to make.
Thanks, -Rob
Hristo has already created a development issue regarding this behavior in the WebDataMenu
88246: “ItemClick” event is not fired when control is inside WebSplitter control
The both controls are navigation controls and the same behavior will be observed in WebDataMenu and WebDataTree.
Let us know if you have further questions
Hi,
Not sure if it was fixed but i have simillar issue posted in tread
http://community.infragistics.com/forums/p/61618/311945.aspx#311945
with small workaround, might be useful.
CHeers