
Erik Stell
Top achievements
Rank 1
Erik Stell
asked on 26 Mar 2014, 02:39 PM
Prior to the recent 2014.1.318 release, it was possible to obtain the id of a table in the event object in javascript, like so:
function DoSomethingForThisTable(e){
var id = e.sender.options.table.context.id;
//get the table with this id and do things
}
However, after the release, this process fails, as the table object on the e.sender.options is now always null. Is there an alternative to doing this, or is this a bug?
function DoSomethingForThisTable(e){
var id = e.sender.options.table.context.id;
//get the table with this id and do things
}
However, after the release, this process fails, as the table object on the e.sender.options is now always null. Is there an alternative to doing this, or is this a bug?
5 Answers, 1 is accepted
0
Hi Erik,
From the provided information it's not clear for us what is the exact scenario that you have nor what is the event that you are referring to - could you please small runable example where the issue is reproduced?
Regards,
Vladimir Iliev
Telerik
From the provided information it's not clear for us what is the exact scenario that you have nor what is the event that you are referring to - could you please small runable example where the issue is reproduced?
Regards,
Vladimir Iliev
Telerik
Build cross-platform mobile apps using Visual Studio and .NET. Register for the online webinar on 03/27/2014, 11:00AM US ET.. Seats are limited.
0

Erik Stell
Top achievements
Rank 1
answered on 28 Mar 2014, 03:28 PM
A modified version of one of your own examples:
Event Function:
Before the 2014.1.318 release, the e.sender.options.table.context.id path would return the ID of "grid". As of now, the e.sender.options.table value is always null, which errors out the process.
@(Html.Kendo().Grid<
Kendo.Mvc.Examples.Models.OrderViewModel
>()
.Name("grid")
.Columns(columns => {
columns.Bound(p => p.OrderID).Filterable(false).Width(100);
columns.Bound(p => p.Freight).Width(100);
columns.Bound(p => p.OrderDate).Format("{0:MM/dd/yyyy}").Width(140);
columns.Bound(p => p.ShipName);
columns.Bound(p => p.ShipCity).Width(150);
})
.Pageable()
.Sortable()
.Scrollable()
.Filterable()
.HtmlAttributes(new { style = "height:430px;" })
.DataSource(dataSource => dataSource
.Ajax()
.Events(e => e.RequestStart("ActivateBusyMode"))
.PageSize(20)
.Read(read => read.Action("Orders_Read", "Grid"))
)
Event Function:
function
ActivateBusyMode(e) {
try
{
kendo.ui.progress($(
"#"
+ e.sender.options.table.context.id +
" div.k-grid-content:first"
),
true
);
}
catch
(er) {
alert(
"Fail!"
);
}
}
Before the 2014.1.318 release, the e.sender.options.table.context.id path would return the ID of "grid". As of now, the e.sender.options.table value is always null, which errors out the process.
0
Accepted
Hi Erik,
Please note that the current behavior is expected and intended - the DataSource shouldn't know about the widgets that are using it as single DataSource can be used by several widgets. Previously the Grid table was accessible in the DataSource due to bug which is fixed in the latest official release.
Possible solution to access the Grid from it's DataSource events is to use anonymous function which to pass the name of the Grid as demonstrated in the following example:
Regards,
Vladimir Iliev
Telerik
Please note that the current behavior is expected and intended - the DataSource shouldn't know about the widgets that are using it as single DataSource can be used by several widgets. Previously the Grid table was accessible in the DataSource due to bug which is fixed in the latest official release.
Possible solution to access the Grid from it's DataSource events is to use anonymous function which to pass the name of the Grid as demonstrated in the following example:
.DataSource(dataSource => dataSource
.Ajax()
.Events(e => e.RequestStart(@<text>
function(e) {
ActivateBusyMode(e,
'grid'
);
}
</text>))
function
ActivateBusyMode(e, gridName) {
try
{
kendo.ui.progress($(
"#"
+ gridName +
" div.k-grid-content:first"
),
true
);
}
catch
(er) {
alert(
"Fail!"
);
}
}
Regards,
Vladimir Iliev
Telerik
Build cross-platform mobile apps using Visual Studio and .NET. Register for the online webinar on 03/27/2014, 11:00AM US ET.. Seats are limited.
0

Mike
Top achievements
Rank 2
answered on 23 Apr 2014, 09:02 PM
Want to disagree with the assertion that the datasource, as being consumed in events triggered by a widget should not know about the widget.
In fact it makes perfect sense that the datasource should be fully informed of the widget currently consuming it and ultimately responsible for triggering the event.
At the very least this change should be noted as a 'breaking change', since it does seem many people were depending upon it, myself included.
The proposed workaround seems kludgey in comparison.
In fact it makes perfect sense that the datasource should be fully informed of the widget currently consuming it and ultimately responsible for triggering the event.
At the very least this change should be noted as a 'breaking change', since it does seem many people were depending upon it, myself included.
The proposed workaround seems kludgey in comparison.
0
Hi Erik,
If you believe that current behavior is not correct I would suggest to share your idea at KendoUI UserVoice to allow other users vote, evaluate and comment on it. Most voted ideas are included in next KendoUI releases.
Regards,
Vladimir Iliev
Telerik
If you believe that current behavior is not correct I would suggest to share your idea at KendoUI UserVoice to allow other users vote, evaluate and comment on it. Most voted ideas are included in next KendoUI releases.
Regards,
Vladimir Iliev
Telerik
Build cross-platform mobile apps using Visual Studio and .NET. Register for the online webinar on 03/27/2014, 11:00AM US ET.. Seats are limited.