Please accept our sincere appologies for the problem. We were able to reproduce it, and have prepared a workaround in the following sticky forum thread
The omission is clearly on our end, and I am deeply sorry for the frustration caused. Perhaps shedding more light on the origins of the issue is needed. By default VisibleDuringInit property is set to true.When it is set to false, the splitter renders invisible and is then shown once it completes calculating its size, and the size of its child panes. The way this was done has been changed from Q2 to Q3, and hence the introduction
of the problem. The change was made because of reports that elements, whose visibilitty is explicitly set to style=visibility:visible, are visible during the splitter intialization process, which was, of course, undesireable.
So, a new mechanism for hiding the splitter and its contents was devised. However, due to a bug in Internet Explorer rendering engine, the new mechanism turned out to expose the problem you encountered. If you examine your pages in any other supported browser, e.g. FireFox or Safari, you will notice that your controls render fine and are visible.
The problem "slipped under the radar" of our QAs for the following reasons:
- It is not manifested always, even in IE.
- The property must be set explicitly to encounter the problem, as the default property value is different.
- The problem only occurs in IE
and most important - the problem could not (and cannot) be detected by our our automated tests - since it is a purely visual (that is, everything is "technically" visible - even for IE - you can use a tool such as IEDevToolbar to verify that).
As a result, we are in the process of implementing additional procedures related to testing RadSplitter to ensure a problem of this kind does not occur again.
please contact us with a support message, and we will send you a custom build DLL as well.
the Telerik team
Check out Telerik Trainer
, the state of the art learning tool for Telerik products.