Ken Hawley
Top achievements
Rank 1
Rank 1
Ken Hawley
asked on 20 Aug 2012, 10:35 PM
I was implementing a treeview in a combobox nearly identical with the demo here:
http://demos.telerik.com/aspnet-ajax/treeview/examples/functionality/treeviewcombobox/defaultcs.aspx?product=treeview
The implementation is .NET in an update panel running in Chrome. I found that the the tree view nodes would display corrrectly and would collapse as expected. Once collapsed they would not re-expand. I examine the <UL> tags in the Chrome developer tool and discovered that the nodes had "display: none" style tags that were inserted on collapse but not removed on expand.
I found, via trial and error, that adding a expandanimation-type="None" attribute to the RadTreeView resolves the problem. Actually, I slapped my head on finding that as we have seen that same behavior in our other RadTreeView uses and I had forgotten. It's a nasty little problem.
The demo has ExpandAnimation-Type="None" CollapseAnimation-Type="None" on the container RadComboBox, but NOT on the RadTreeView and yet it works. Mine would only work when the expandanimation-type was also on the RadTreeView.
Your demo, by the way, works fine in Chrome as it. So clearly there is some odd combination of JS and .NET on my page that makes this happen. I point this out only as a possible help to someone else who might be tempted to punch a monitor as I was. This little flaw is not in the forum as far as I was able find. Thanks.
http://demos.telerik.com/aspnet-ajax/treeview/examples/functionality/treeviewcombobox/defaultcs.aspx?product=treeview
The implementation is .NET in an update panel running in Chrome. I found that the the tree view nodes would display corrrectly and would collapse as expected. Once collapsed they would not re-expand. I examine the <UL> tags in the Chrome developer tool and discovered that the nodes had "display: none" style tags that were inserted on collapse but not removed on expand.
I found, via trial and error, that adding a expandanimation-type="None" attribute to the RadTreeView resolves the problem. Actually, I slapped my head on finding that as we have seen that same behavior in our other RadTreeView uses and I had forgotten. It's a nasty little problem.
The demo has ExpandAnimation-Type="None" CollapseAnimation-Type="None" on the container RadComboBox, but NOT on the RadTreeView and yet it works. Mine would only work when the expandanimation-type was also on the RadTreeView.
Your demo, by the way, works fine in Chrome as it. So clearly there is some odd combination of JS and .NET on my page that makes this happen. I point this out only as a possible help to someone else who might be tempted to punch a monitor as I was. This little flaw is not in the forum as far as I was able find. Thanks.
3 Answers, 1 is accepted
0
Hello Ken,
I have managed to perform some tests locally, with the mentioned demo, but there seems to be no such problem as the described one. There could be other reasons for the problematic behavior at your end. For that matter, you could provide us a snippet with the implementation, used at your end, so we could have a closer look and examine the problem?
Regards,
Nencho
the Telerik team
I have managed to perform some tests locally, with the mentioned demo, but there seems to be no such problem as the described one. There could be other reasons for the problematic behavior at your end. For that matter, you could provide us a snippet with the implementation, used at your end, so we could have a closer look and examine the problem?
Regards,
Nencho
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
0
Ken Hawley
Top achievements
Rank 1
Rank 1
answered on 22 Aug 2012, 02:36 PM
I am guessing that some peculiar combination of script manager and other JS on our page is probably tripping up the collapse logic.
As I mentioned, we have seen this issue on other pages and find that the work around is to always specify the animation-type attribute. Why that works I don't know, but apparently it makes the "expand" code path sufficiently different that the control behaves correctly. If you want to keep digging on the issue, I would suggest you start with differences between the code paths when the attribute-type is specified and when it is left to the default. Is it possible the assignment of the default is under-qualified in the JS namespace so that other code on the page might interfere with it? Or the problem could be in the logic to remove the "display: none" style on expand ... that clearly is not happening in the case where the animation-type is the default.
Given that we have a workaround, I can't justify the time to extract everything to send to you. I realize that is not very neighborly, but our pages (1) are extraordinarily complex, (2) use non-standard ASP.NET structure, (3) have a large JS component -- ours, Telerik, and others, (4) are not using the very latest Telerik versions, and finally (5) cover proprietary topics that would have to be sanitized to send to you. All that makes it a big job to send you anything and you would probably have to have all of it to replicate the problem. Sorry.
If the work-around I describe is helpful to someone else who happens to have the same issue, that will have to be sufficient.
If I get a little time in the next few days, I might spend it in the debugger and see if I can find the code path difference.
As I mentioned, we have seen this issue on other pages and find that the work around is to always specify the animation-type attribute. Why that works I don't know, but apparently it makes the "expand" code path sufficiently different that the control behaves correctly. If you want to keep digging on the issue, I would suggest you start with differences between the code paths when the attribute-type is specified and when it is left to the default. Is it possible the assignment of the default is under-qualified in the JS namespace so that other code on the page might interfere with it? Or the problem could be in the logic to remove the "display: none" style on expand ... that clearly is not happening in the case where the animation-type is the default.
Given that we have a workaround, I can't justify the time to extract everything to send to you. I realize that is not very neighborly, but our pages (1) are extraordinarily complex, (2) use non-standard ASP.NET structure, (3) have a large JS component -- ours, Telerik, and others, (4) are not using the very latest Telerik versions, and finally (5) cover proprietary topics that would have to be sanitized to send to you. All that makes it a big job to send you anything and you would probably have to have all of it to replicate the problem. Sorry.
If the work-around I describe is helpful to someone else who happens to have the same issue, that will have to be sufficient.
If I get a little time in the next few days, I might spend it in the debugger and see if I can find the code path difference.
0
Hi Ken,
Thank you for sharing your findings with the community. We understand - the project is complex and it will not be easy to isolate the issue.
We would be happy if the workaround helps others, facing a similar problem.
Regards,
Nencho
the Telerik team
Thank you for sharing your findings with the community. We understand - the project is complex and it will not be easy to isolate the issue.
We would be happy if the workaround helps others, facing a similar problem.
Regards,
Nencho
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.