In my attachment on the left is the result with not using a primaryKey ( this is desired ). If I use a primaryKey I get what you see on the right.
The header column name for the first column you see is an under score. It does not matter what I set the primaryKey to both cause this strange result.
my data is as follows: [{"_":"Adaptive Control Switch","Value":"1"},{"_":"Adaptive Max ACT to Allow Adaptive Learning","Value":"180"},{"_":"Adaptive Max ECT to Allow Adaptive Learning","Value":"230"},{"_":"Adaptive Min ACT to Allow Adaptive Learning","Value":"-20"},{"_":"Adaptive Min ECT to Allow Adaptive Learning","Value":"150"},{"_":"ADEFTR","Value":"0.000225"},{"_":"Adpative Correction Max Allowed Learned","Value":"0.75"},{"_":"Adpative Correction Min Allowed Learned","Value":"0.25"},{"_":"Amplitude Multiplier for Adaptive","Value":"0.52"},{"_":"Dead Band to Not Adapt","Value":"0"},{"_":"Green Engine Adaptive Gain","Value":"1"},{"_":"Load to Define Decel for Adaptive","Value":"0.14"},{"_":"Max TP to Allow Learning","Value":"1023"},{"_":"Min ECT Temp for Adaptive","Value":"150"},{"_":"Min Load to Allow Learning","Value":"0.1"},{"_":"Number Of Warm Up Counters for Fast Adaptive","Value":"5"},{"_":"RPM to Define Decel for Adaptive","Value":"1000"},{"_":"Switch to Shut Off Kam Fuel Reset","Value":"0"},{"_":"Unique Decel Kam Cell Switch","Value":"1"},{"_":"Warm Up Temp for Adaptive After Start","Value":"120"}]
my column are : [{"headerText":"_","key":"_","dataType":"string"},{"headerText":"Value","key":"Value","dataType":"string"}]
This is how I do my checkboxes in my rows loop
this.gridIDMap.cellAt( 0, rows ).innerHTML = "<input name = 'check" + rows + " align='left' type='checkbox'>" + this.gridIDMap.getCellText( rows, _spaceChar )
I think I follow you a bit here, but I want to make it clear that its not that I dont want to use the workaround. Its that it does not work, maybe in theory it does but there are inconsistencies in the way I outlined already.
So you're thinking of a direct text update of the displayed data? The question then is will it update the datasource JASON records. Assuming not, will there be another way to get all changed data in an array like format. Or, at most a way to get the changed text later with a row,col function of sorts so that I can write a function to get all the changed data.
Hello,
Thank you for your patience. We have done some discussing with our development team. Since you don’t want to use a primary key the alternative to having a hidden column with the primary key would be to use the API to do the updating. If you use the API to do the updating of cells. You won’t need the updating and it can be replace by selecting a cell with jQuery to update the text directly then doing the same for the corresponding record in the data source. I am currently working on a sample to demonstrate this behavior. I will continue to work on this sample and will update you by tomorrow with my progress.
Hi Jason, yes this was suggested before. Unfortunately it didn't work out well because not all methods take in to consideration the hidden columns in the same way. This was talked about here http://ko.infragistics.com/community/forums/p/80484/422424.aspx#422424
Trying to massage the code and compensate for all the loops became futile at best. So we are asking for a feature rather then a work around at this point. There was a bug in the code that allowed updates with no primary key during our year of development. We are asking for this bug to because a feature.
The grid requires a primary key for updates as generally the updates will be pushed back to a server of some kind and there needs to be a mechanism to identify exactly which records need to be updated. That said, if you really don't require the primary key but still want to do updates you can always add a dummy column.
Since you're using an array of JavaScript objects for your data collection you can easily add on a field to each record by looping through the collection and calling [object].[new field name] = value. After that, add a hidden column to your grid and set it as the primary key, though just make sure the logic for adding the additional field comes before the instantiation of the grid or you may get an error stating that the field doesn't exist.
I've attached an HTML file that uses this approach. Just remember that doing this makes the primary key essentially meaningless, but for the purposes you describe it should work.
Deyan, here is the deal. We wrote a large piece of software with infragistics. Basically it displays lots of tables/grids. To update a cell we double clicked on it and the data changes. Now for what ever reason infragistics decided this primary thing had to be there when updating a cell. This basically busted all of our code. You can read some about that here.
http://ko.infragistics.com/community/forums/p/80484/422424.aspx#422424
Now I had to find a way to satisfy this primary key thing so that we can continue working on our software. As you can see in that posting there were some suggestions about hiding a column but what I found worked best was just to pick some random column and call it a primary key. This fixes our main issues and allowed is to continue to work. Now here and there I keep running into all of these quirks with the primary key stuff. There is no need for a primary key. That is just crazy talk. Worked fine without it so I dont see why it needs to be there. Though I'm sure that does not mean much to the infragistics team :) However as it stands I have no choice but to deal with this.
To fix the issue?
I either need to find a way to call a column a primary key and allow it to work like ever other column or I need the infragistics code fixed so that its consistent and i'll go back to hiding the primary key column. By inconsistent I mean the things noted in that link above. So I'm now in a catch 22 here. All of this because a primary key is now enforced. Just a lot of work for no reason as I see it.
So to make this as short and simple as possible I just want to be able to update a cell without the need of a primary key. Our software just sees this grid as a grid of data, not some link to a database that requires updates.
We love infragistics and it has worked so well for us. One of the best things about the software was how polymorphic it was. You could use it so many ways and it was so adaptable. We really felt the team understood how companies like to work with flexible code not rigid design. This entire primary key decision is undoing all of that. Not everyone will use the grid as a database, some just like to display data and manipulate it.
Please provide us with a solution so that we can continue to use this software.