Weird situation. We have two RadTreeViews, one for "available" critieria and one for "selected". As users pulls a node from "available" to "selected", we open a RadWindow to let them specify the settings for that criteria (example: pull over the "user name" node, we pop a window to let them select equals/starts with/contains and type in a value).
In Chrome, each time the window is dragged over, the height increases by exactly 39 px. Height doesn't change in IE9, but it doesn't seem to autosize to what I'd expect either--it picks 300px for reasons which escape me.
In the page containing our trees, here's how we define the RadWindow:
and when the drag happens, here's how we open it:
(I put the alert in just to see what the _height parameter is immediately upon referencing it. In Chrome, it goes from 300 to 339 to 378..., even if we pull the same node over [i.e., we're displaying the exact same set of controls, which should calculate the same height]).
A bit of detail, if it's of interest: our modal content is a RadSplitter (horizontal) with three RadPanes. The middle one has a table with a series of Panels in it. Depending on the type of node that's dragged over, we make the appropriate Panel visible (one has text-type input, one has date controls, et cetera).
So there's a bit of dynamicness there, but pulling the same node over repeatedly means we're going to make the same Panel visible with the same controls, so height should be calculated the same.
I'm working on this as a low-priority project, trying to put together a sample in extra time for you guys; so, it might be a while until I can get that together. At this point, just wondering if anything like this has been reported, and, if so, what I might focus on.
In Chrome, each time the window is dragged over, the height increases by exactly 39 px. Height doesn't change in IE9, but it doesn't seem to autosize to what I'd expect either--it picks 300px for reasons which escape me.
In the page containing our trees, here's how we define the RadWindow:
<
telerik:RadWindow
ID
=
"CriteriaModal"
runat
=
"server"
Modal
=
"true"
AutoSize
=
"true"
AutoSizeBehaviors
=
"Height"
VisibleStatusbar
=
"false"
ShowContentDuringLoad
=
"false"
Width
=
"600px"
Behaviors
=
"Resize, Close, Move"
OnClientClose
=
"adHocCriteria.editNodeReturnHandler"
RestrictionZoneID
=
"radWindowZone"
>
</
telerik:RadWindow
>
and when the drag happens, here's how we open it:
adHocCriteria.editNode =
function
adHocCriteria_editNode(node, logical, logicLocked) {
if
(logicLocked)
logical = logical +
'_LOCKED'
;
// VALUE == FieldLabel \b FieldID \b Operator \b Value
var
paramValue =
'fieldId='
+ encodeURI(logical +
'\b'
) + node.get_value();
adHocCriteria._editNode = node;
var
modalDialog = adHocCriteria_GetModalWindow();
alert(
'showing modal, height is '
+ modalDialog._height);
modalDialog.setUrl(adHocCriteria_GetAdHocCriteriaDetailsModalUrl() +
'?'
+ paramValue);
modalDialog.show();
}
(I put the alert in just to see what the _height parameter is immediately upon referencing it. In Chrome, it goes from 300 to 339 to 378..., even if we pull the same node over [i.e., we're displaying the exact same set of controls, which should calculate the same height]).
A bit of detail, if it's of interest: our modal content is a RadSplitter (horizontal) with three RadPanes. The middle one has a table with a series of Panels in it. Depending on the type of node that's dragged over, we make the appropriate Panel visible (one has text-type input, one has date controls, et cetera).
So there's a bit of dynamicness there, but pulling the same node over repeatedly means we're going to make the same Panel visible with the same controls, so height should be calculated the same.
I'm working on this as a low-priority project, trying to put together a sample in extra time for you guys; so, it might be a while until I can get that together. At this point, just wondering if anything like this has been reported, and, if so, what I might focus on.