We recently upgraded our AJAX Control Toolkit from v4.1.7.0607 to v4.1.7.1213 and for the most part things are working fine, except for the TabContainer that we have been using in the previous version, now seems to no longer work.
Originally we were making use of OnClientActiveTabChanged="EditActiveTabChanged" client-side event to handle a postback when a Tab was clicked. The client-side function is below and modified accordingly for what we believe are the correct methods/functions for the new version.
Note: variables in function below are set programmatically using RegisterStartupScript
function EditActiveTabChanged(sender, e)
{
ShowMessageDiv('cphMainContent_upEdit');
var strPreviousTabIndex = 0;
var strNewTabIndex = 0;
strPreviousTabIndex = strNewTabIndex;
strNewTabIndex = sender.get_activeTabIndex();
__doPostBack('cphMainContent_tbcEdit', strPreviousTabIndex + ',' + strNewTabIndex);
}
The problem is that the postback is happening, however the server side event/method is not firing i.e. OnActiveTabChanged="EditActiveTabChangedServer". We have the TabContainer wrapped in an update panel, with the following Trigger, <asp:AsyncPostBackTrigger ControlID="tbcEdit" EventName="ActiveTabChanged" />. In the previous version, we did not need to set the AutoPostBack option on the TabContainer as this event automatically fired when the postback was called.
The client-side script is registered with RegisterStartupScript in the appropriate places in the server-side code and we have checked it 'syntax-wise' and there are no errors. For some reason, from the previous version to this new version, this method of issuing a postback is no longer working and therefore all our existing server-side code is no longer valid.
If I set AutoPostBack="true", then the server-side event fires, however I no longer have my event arguments available in order to do my validation. Also, one of the reasons why we utilised the client-side event to trigger the postback, was so that we could 'blank' the next tab panel, ShowMessageDiv('cphMainContent_upEdit'); and prepare the next tab according to what was inputted on the previous tab, which worked well and was happy with the results.
We do not want to rollback to the previous version as there is certain functionality that we require in the new version and hence why we upgraded in the first place.
Any help on the matter will be much appreciated.
Thanks
Comments: Hi there, we managed to solve this issue, so some feedback for those that may be interested. We used JetBrains dotPeek to look at the IPostBackEventHandler method to determine what the RaisePostBackEvent method was doing and noticed that the eventArgument needs to be in the following format:- activeTabChanged:(int) - where (int) is the ActiveTabIndex being called So this meant we needed to change the __doPostBack eventArgument to suit. More interestingly, the eventTarget was using controlRenderingCompatibilityVersion client identifiers and therefore cphMainContent_tbcEdit above was invalid. When we changed this to ctl00$cphMainContent$tbcEdit, everything started to work as before. Not sure why the eventArgument format changed from version to version, however there must be good reason for this change. We are more concerned however that the eventTarget is using the old rendering mode for ClientID.
Originally we were making use of OnClientActiveTabChanged="EditActiveTabChanged" client-side event to handle a postback when a Tab was clicked. The client-side function is below and modified accordingly for what we believe are the correct methods/functions for the new version.
Note: variables in function below are set programmatically using RegisterStartupScript
function EditActiveTabChanged(sender, e)
{
ShowMessageDiv('cphMainContent_upEdit');
var strPreviousTabIndex = 0;
var strNewTabIndex = 0;
strPreviousTabIndex = strNewTabIndex;
strNewTabIndex = sender.get_activeTabIndex();
__doPostBack('cphMainContent_tbcEdit', strPreviousTabIndex + ',' + strNewTabIndex);
}
The problem is that the postback is happening, however the server side event/method is not firing i.e. OnActiveTabChanged="EditActiveTabChangedServer". We have the TabContainer wrapped in an update panel, with the following Trigger, <asp:AsyncPostBackTrigger ControlID="tbcEdit" EventName="ActiveTabChanged" />. In the previous version, we did not need to set the AutoPostBack option on the TabContainer as this event automatically fired when the postback was called.
The client-side script is registered with RegisterStartupScript in the appropriate places in the server-side code and we have checked it 'syntax-wise' and there are no errors. For some reason, from the previous version to this new version, this method of issuing a postback is no longer working and therefore all our existing server-side code is no longer valid.
If I set AutoPostBack="true", then the server-side event fires, however I no longer have my event arguments available in order to do my validation. Also, one of the reasons why we utilised the client-side event to trigger the postback, was so that we could 'blank' the next tab panel, ShowMessageDiv('cphMainContent_upEdit'); and prepare the next tab according to what was inputted on the previous tab, which worked well and was happy with the results.
We do not want to rollback to the previous version as there is certain functionality that we require in the new version and hence why we upgraded in the first place.
Any help on the matter will be much appreciated.
Thanks
Comments: Hi there, we managed to solve this issue, so some feedback for those that may be interested. We used JetBrains dotPeek to look at the IPostBackEventHandler method to determine what the RaisePostBackEvent method was doing and noticed that the eventArgument needs to be in the following format:- activeTabChanged:(int) - where (int) is the ActiveTabIndex being called So this meant we needed to change the __doPostBack eventArgument to suit. More interestingly, the eventTarget was using controlRenderingCompatibilityVersion client identifiers and therefore cphMainContent_tbcEdit above was invalid. When we changed this to ctl00$cphMainContent$tbcEdit, everything started to work as before. Not sure why the eventArgument format changed from version to version, however there must be good reason for this change. We are more concerned however that the eventTarget is using the old rendering mode for ClientID.