3 Answers, 1 is accepted
I assume that you mean that you have a RadDatePicker by saying RadCalendar because this is the control which dynamically changes its size (due to showing/hiding of the calendar popup). If so, I suggest to hook up the OnPopupOpening and OnPopupClosing events and to use the built-in autosize function of the RadWindow to adjust it to the new size. Below is sample code which should be placed in the RadWindow's content page:
<form id="form1" runat="server"> |
<script type="text/javascript"> |
function GetRadWindow() |
{ |
var oWindow = null; |
if (window.radWindow) oWindow = window.radWindow; //Will work in Moz in all cases, including clasic dialog |
else if (window.frameElement.radWindow) oWindow = window.frameElement.radWindow;//IE (and Moz as well) |
return oWindow; |
} |
function AdjustRadWidow() |
{ |
setTimeout(function(){GetRadWindow().autoSize()}, 200); |
} |
</script> |
<asp:ScriptManager ID="ScriptManager1" runat="server"> |
</asp:ScriptManager> |
<telerik:RadDatePicker ID="RadDatePicker1" runat="server" > |
<ClientEvents OnPopupOpening="AdjustRadWidow" OnPopupClosing="AdjustRadWidow" /> |
</telerik:RadDatePicker> |
In case this is not what you meant, please provide more detailed explanations or best - open a new support ticket and send us a sample, fully runnable demo along with detailed reproduction steps and explanations.
Sincerely yours,
Svetlina
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Any input will be appreciated.
Thank you for your report, we are aware of this problem but unfortunately it is not an easy one to easily fix it in the source code.
The problem comes from the fact that calendar popup has absolute position and under Chrome and Safari it is not treated as part of the content page layout. As a result it does not change the size of the content and autosize does not change the window size.
We are currently working on finding a reliable fix for this specific situation and we prepared a temporary workaround which is as follows (regarding the our demo):
function
AdjustRadWidow()
{
var
oWindow = GetRadWindow();
setTimeout(
function
() { oWindow.autoSize(
true
);
if
($telerik.isChrome || $telerik.isSafari) ChromeSafariFix(oWindow);}, 500);
}
//fix for Chrome/Safari due to absolute positioned popup not counted as part of the content page layout
function
ChromeSafariFix(oWindow)
{
var
iframe = oWindow.get_contentFrame();
var
body = iframe.contentWindow.document.body;
setTimeout(
function
()
{
var
height = body.scrollHeight;
var
width = body.scrollWidth;
var
iframeBounds = $telerik.getBounds(iframe);
var
heightDelta = height - iframeBounds.height;
var
widthDelta = width - iframeBounds.width;
if
(heightDelta > 0) oWindow.set_height(oWindow.get_height() + heightDelta);
if
(widthDelta > 0) oWindow.set_width(oWindow.get_width() + widthDelta);
oWindow.center();
}, 310);
}
The changes in the demo as above fix it - please test this in your scenario as well. Note, that depending on your window content you might experiment with the 310 ms timeout - if e.g you do not need to wait for animation for popup, etc you can reduce it or you should increase it if there is a longer animation.
The fixed demo will be uploaded in the upcoming SP release which is scheduled for today.
We understand that this is not the best solution but there are many scenarios when autosize is used with different contents and browser specific behavior in all theses cases makes it hard sometime to quickly find a reliable fix which will not break current functionality. However, I can confirm that this is logged in our TODO list for future research.
Svetlina
the Telerik team