When enabling the sort on kendo grid columns it will work as expected,
except the case when the column being sorted contains negative numbers.
Is there any way to fix this problem ?
this is a screen-shot of my grid:
Fixed: Sorting on negative numbers and zeros does not work as expected with Q3 2012 SP1
http://www.telerik.com/support/whats-new/kendo-ui-web/release-history/q3-2012-sp1-version-2012-3-1315
which version is your kendo ?
You are not providing enough information for determining what might be wrong so I will have to work in hypothesis...
The version that you mention works fine (I just tried it)
Sorting might fail if column that contains negative "numbers" is not defined in the model and then KendoUI needs to infer the type of the data and might be guessing that they are strings. See this example http://jsfiddle.net/4aD6b/2/ where Value is defined as string and try sorting it. But if you define conveniently the model (see http://jsfiddle.net/4aD6b/3/) then it works perfectly well.
So, try defining the model as follow:
schema : {
model: {
fields: {
...,
Value : { type: 'number' }
}
},
If this is not the case then update your post showing code and mostly how the data is sorted in your case.
I got the same problem, found out that my model's property contains null and not number (during assignment from server side ajax), so I just change all null to 0 and sorting works
Related
I have a requirement to filter out blank cells OR non-blank cells for a given column. I could imagine a custom header formatter function that would add a control in the header to do this, but I would need to write a lot of code for this, right? Both the headerFilter and the function would take significant custom coding. Am I over-thinking this problem? even if there is nothing built in to tabulator, is there an easy way to do it?
It is not clear from your question what you are looking to filter.
If you want to filter out rows if the value of a certain property is empty then you can use a filter function (in this case im using the age field):
table.setFilter(function(data){
return !!data.age;
});
I am currently trying to work out how to make the current Google Sheets version of COUNTIF properly count how many times the value of a cell (C3) is higher than the value if another cell (E3), according to the following formula:
=COUNTIF('4'!$C$3,">'4'!$E$3")
You'll note that the formula is run in a different tab than the one where the cells being counted are located in (which is named "4"). The formula returns a zero '0', when it should be returning a one '1', as the value in '4'!$C$3 actually is higher than the value in '4'!$E$3.
Clearly, I am doing something wrong.
So, the user I'-'I (stackoverflow.com/users/8404453/i-i) suggested the following edit:
=COUNTIF('4'!$C$3,">'4'!$E$3") --> COUNTIF('4'!$C$3,">"&'4'!$E$3)
This suggestion resolved my issue.
I am using a Kendo spreadsheet to import data from an Excel file so I can plug it into an SQL Server database using Ajax callbacks. The Ajax callbacks work fine, but I have determined that any Date strings are being converted to an integer offset from a base date of 12/30/1899. I have submitted a support ticket to Telerik, but they do not seem to understand the problem.
The data is displayed in the Kendo spreadsheet appropriately as a date. Kendo converts a date input as "12/1/2015" to "12-1-2015".
I am using the latest version of the ASP.NET MVC 5 wrapper, but the JavaScript code is the 2016-1-226-545 version of the JavaScript. The wrapper version seems to be irrelevant, but later versions of the JavaScript have the gulpfile.js, and this conflicts with the Bundleconfig interface on my ASP.NET MVC 5 project, so I simply work with the last version of the JavaScript that works for my setup.
The spreadsheet I am working with is pretty basic to start:
#(
Html.Kendo().Spreadsheet()
.Name("SiteSlotDataSS")
.Rows(10)
.Columns(4).ColumnWidth(100)
.Sheets(sheets =>
{
sheets.Add()
.Name("Study Data");
}
)
)
I use the import option to pull in an Excel spreadsheet and use a simple button with a click event routine to copy the data to a string array to send to the Ajax callback. I have confirmed that the data being sent to the server controller is the same as it is on the client side before being sent. The Date conversion to an integer occurs when the values are extracted from the range.
The code in question that selects the values is:
values = sheet.range("A" + headerRows.toString() + ":" + endRange + (headerRows + rows).toString()).values();
This produces the correct translation of every other column except for columns containing dates.
I tried the following to brute-force the issue, without success:
for (var x = 0; x <= rows; x++) {
sheet.range("K" + (headerRows + x).toString()).format(kendo.spreadsheet.formatting.date);
}
I could try a date function to convert the date back into the original value, but everyone pretty much knows how Telerik's documentation is a bit skimpy and overall simply a nightmare to find answers to questions with.
What is the solution?
It appears that Kendo Spreadsheet stores the date values as an integer offset from 12/30/1899 in days. I determined the "0" value by entering a date of 1/1/1901 to see what came back, then 1/1/1900. The result of the latter was "2", making the base date 12/30/1899. Taking the data and converting it at the server seems to be the best option. I don't really expect much of a response from Telerik.
I have addressed the storage issue with Telerik, and they have acknowledged there is a bug in the spreadsheet widget.
For now, the solution is to bring the values array one row at a time back to the server and do the data conversion server-side. The integer that is returned in the values array for dates is the way the Kendo Spreadsheet stores the information client-side. Formatting the column simply will not do anything but change the client-side display. It will not change how Kendo returns the values matrix from the spreadsheet range selected.
Firstly, I think you mean 12/31/1899. It makes no sense to refer anything to 12/30/1899.
Excel dates start with 1/1/1900, just as do your Kendo (Japanese: "the way of the sword") dates. If you're getting an integer, forcibly coerce it to the corresponding date on the receiving by merely FORMATTING THE COLUMN. There is no need for a specific function to "convert" days-since-1900 counts to text dates (MM/DD/YYYY), as they are the SAME, differing only in human-readable representation.
Of course, it wasn't clear from your description whether Excel was on the input side or the output side of the problem.
I've hit a pretty major snag with the entities generated by spmetal / linq to sharepoint. I am hoping someone has dealt with this before.. or maybe I am missing something obvious.
Let's say we have a list with a number field. The field will be expected to hold reasonably precise values.. for example, 0.0000451. Once the value is in the list- SharePoint is fine with it. It displays in the list and display/edit views correctly.
Now if we generate entities based on this list with spmetal, we will get..
//...
private System.Nullable<double> _number;
//..
[Microsoft.SharePoint.Linq.ColumnAttribute(Name="Number", Storage="_number", Required=true, FieldType="Number")]
public System.Nullable<double> Number {
get {
return this._number;
}
set {
if ((value != this._number))
{
this.OnPropertyChanging("Number", this._number);
this._number= value;
this.OnPropertyChanged("Number");
}
}
}
//...
Since the type determined by spmetal is doublewe get notation when trying to retrieve it.. for example:
var number = (from x in myDc.MyList select x.Number).First();
number would actually result in a double of 4.51E-05, not 0.0000451.
I am assuming this can be fixed by using a decimal. If I change the types throughout the generated entities to System.Nullable<decimal> I get type conversion failures.
How should I fix this?
EDIT I think maybe it is better to ask "how should I deal with this"? for example, I can simply convert my double values to decimal later on down the line.. my linq query, for example. If I do that, the example case would return the expected result. That seems clunky, though, and I'd like to correct this at the source.
There are several cases like this where SPMetal will give you clunky code. You can, and sometimes have to, fix that. And I admit, it definitely feels better to do it at the source.
But there is a downside.
When your data model changes you will have to re-run SPMetal to incorporate your new entities. Any changes you made to the generated file will have to be carefully documented and re-done, or your code will be broken. Therefore, I would advise to leave the generated code alone if you can work with it.
If you can write a wrapper around the objects/methods it would of course be preferable to just converting the types at the end-point, but that's general good programming practice.
4.51E-05 actually equals 0.0000451 so there is nothing wrong with your code.
In other words 4.51E-05 means 4.51 times ten to the minus five power, or 0.0000451
I'm using SMOTE to oversample my dataset (affected by class imbalance). Some of my attributes have integer values, others have only two decimals but SMOTE creates new instances with many decimals. So to solve this problems I thought to use NumericCleaner Filter and set the number of decimals I desire. This seems to work but I've got problems with missing values. Each missing values is replaced with a 0.0 value, I need to evaluate my model using missing values in dataset. So how can I use NumericCleaner (or other filters that permit to round values) and keep my missing values?
Very interesting question. Okay, here is the solution:
use SMOTE to oversample the minority group (this produces decimal points but the missing values remain missing values)
then select weka filter->unsupervised->attribute->NumericTransform
then click on this filter and set the attribute instances (where you are having decimal points features) and in the methodName instead of "abs", put "ceil".
I hope that solves the problem.