I recently noticed when double clicking on a cell to enter edit mode the cell inherits data in the top most column?
example grid
120000
If I double click on (row2:col0) my data becomes 1 in that cell, if I ESC to get out its now permanently 1. Same for (row3:col0).
Here is an example of data that causes this
[{"AM":"63.99902","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"}]
Anything I double click on in the AM row assumes 63.99902. If this is not a bug, then would could cause this? My edit starting and started events have no code in them.
FYI: my code has a infragistics suggested work around to the primary key. We dont use the pri key and all of our updates are direct to the TD followed by the JSON data being updated. In order for the code to work right we had to put in a dummy Key and in this case that key would be AM. more info on that here
http://ko.infragistics.com/community/forums/p/85055/430952.aspx#430952
Ok I was right its that primary key stuff. I was able to replicate the issue see code.
please see this http://ko.infragistics.com/community/forums/p/85055/430952.aspx#430952 Per this fix I should be able to use the infragistics code without the primary key. Here is another example of it failing to work. Change primaryKey: "Gain", to primaryKey: "AM", and the code works fine. Please understand ( per that link ) we can not use the pirmary key feature and asked if it were possible to handle updates another way. Setting a null primaryKey value does not work, so it was suggested to put in some random column.
I'm not sure the primary key is the culprit here but changing it make the problem go away. In the example below the following code will work fine. Chance primaryKey: to "AM" and now double clicking on anything under AM changes the cell data.
$.ig.loader(function () { $("#grid1").igGrid({ height: "500px", width: "750px", autoGenerateColumns: false, dataSource: [{"AM":"63.99902","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"},{"AM":"0","Gain":"0.5"}], responseDataKey: "results", dataSourceType: "json", columns: [ { headerText: "AM", key: "AM", dataType: "string", width: "150px" }, { headerText: "Gain", key: "Gain", dataType: "string", width: "150px" }], primaryKey: "Gain", features: [ { name: "ColumnFixing", columnSettings: [ { columnKey: "ProductName", isFixed: true } ], deferredResizing: false, allowDoubleClickToResize: true, columnResizing: function ( ) { return false;//dont want this } }, { name: "Selection", mode: "cell", multipleSelection: true, mouseDragSelect: true, // default value for selecting multiple cells with the mouse touchDragSelect: true, // default value for selecting multiple cells with a finger cellSelectionChanged: function ( evt, ui ) {}, cellSelectionChanging: function ( evt, ui ) {} }, { name: "Updating", editMode: "cell", enableAddRow: false, enableDeleteRow: false, startEditTriggers: "dblclick", editCellStarted: function ( evt, ui ){}, editCellStarting: function ( evt, ui ) { if ( evt.keyCode === 13 ) { //document.forms[0].submit(); return false; } }, editRowEnding: function ( evt, ui ){ }, editCellEnded: function ( evt, ui ){} }, { name: "Sorting", columnSorting: function ( evt, ui ) {} } ] }); });
Hello,
If the value you see in an editor is different than the one in the cell, this most likely means Updating was unable to find the correct record corresponding to the row being edited. If I read your example correctly, setting the primaryKey to "Gain" is very likely the culprit as the values in the Gain column are not unique. When that's the case your editors will get populated with the values of the first record that has the same PK as the one you are trying to edit.
My previous suggestion for updating without PK is only possible if you only update through separate UI, using the grid's API. Using Updating's UI does require an unique PK to avoid such conflicts. What I suggest is to traverse your data before initializing the grid and add a property to use as PK which you populate with a simple index. Then you can hide the column through the column settings:
columns: [
{ key: "Index", dataType: "number", hidden: true }
...
]
I realize you had some issues with this approach previously but I believe these can be worked around more easily than implementing a separate updating UI to circumvent Updating's dependency on a PK. Please, let me know about any issue you have with defining a dummy PK so I can help you with them promptly.
Best regards,
Stamen Stoychev
I think the main issue here is that my testing and workarounds are scattered all over the place. You seem to understand my issue the best so far. The biggest problem here is that too many hands are in the mix in helping this issue. I think its best for both my teams and your team to track this PK issue until fully resolved. Unfortunately I have no way to predict these failures. Please suggest an approach in your reporting system I can trust will find a resolution.
We can not use hidden columns for a 2 main reasons.
1) Your code is inconsistent. I have the link to that info somewhere.
2) We need to count columns on the fly, if your code was consistent I could reply on the counts but its not, so that does not work.
If your not the right person to help our team see this thru please have someone contact me.
If I remember correctly the main issues you experienced by hiding a column were some discrepancies in the grid's API coming from the fact some features work with visual and some with real column indexes. I can't argue that this can be problematic and we are already planning on addressing it for the 14.2 volume release.
In the mean time a general rule with the event arguments and the functions accepting column index parameters is that features that work exclusively with the DOM and not the data source (i.e. Selection) will use visual indexes, while features that modify the data source or data view in some way should work with real indexes. With this said, to switch between the two or get an index by a column key you'll need to process the columns collection and apply some logic to it.
$("#grid1").igGrid("option", "columns"); -> gets the columns collection
$.grep($("#grid1").igGrid("option", "columns"), function (col) { return !col.hidden; }); -> gets only the visible columns
If you can provide me with some examples of where the column indexes are inconsistent between event arguments and function calls I can help you with specific solutions.
As for using the reporting system - we log development issues to our internal system from information on the forums and such will be logged in your case if suspicious behavior is found. For feature requests (such as the ability to use Updating without a PK) you can use the "Submit Product Idea" button to the right.
I am looking forward to hearing from you!
For example if I have a 2 by 2 grid with a hidden field "pri"
col1 col2 ( "pri" hidden )
1_____1
2_____2
I get these results
alert(this.gridIDMap.option( "columns" ).length); 3... no, its hidden so there should only be 2.
alert( this.gridIDMap.cellAt( 2, 0 ).innerHTML ); error this is good because 2 is hidden and that is what I would expect.
now if I unhide and do the same I get this.
alert( this.gridIDMap.option( "columns" ).length); 3... in this case 3 is correct.
alert( this.gridIDMap.cellAt( 2, 0 ).innerHTML ); alerts an empty cell as it should because its empty
So if cellAt takes in to consideration that the cell is not shown then why does columns not?
There was another example I ran in to but it escapes me at the moment.
Now here is what confuses me more then anything. In 1st quarter 2013 the system worked with no PK. Our code executed perfectly and all updates were fine, be it double click or programmatic. Some fix was made enforcing the PK in mid 2013, not sure when. Then all of our updates break. Now I started asking about this mid 2013 and we are now in to feb 2014 and its like I'm going back to the suggestions in mid 2013. It took me 8 months to get to a semi-working point and now I find its no good. My proposal form the very beginning ,humbly, was "would you please consider allowing a null value for PK". Its already proven to work that way as it did for us in the beginning of 2013.
If that is in some way unacceptable, you know our issue. We simple want to load data in to a chart and then make edits. No match data base is used ( WYSIWYG ). If the internal update function will not work because of a missing PK ( even though at one time it did ) could you offer a new way to go about this. I think the only issue left is this double click. I dont really need it to work I just need the events. Maybe its best to disable the grid dblck and over right it with jquery? The only thing we need the event to do is start edit on a cell, and enter to save the new value. No need to use the internal grid dblck at all. I have not considered this yet.
Adding this hidden key was a disaster last time but more importantly we would like a solution that wont come back to haunt us. If you do prescribe a method here, I'd like to know I'm not going to run in to more PK issues down the road.
Hi seang,Referring back to my previous post, we understand the scenario you are describing. This is by design, and by that I mean the TD elements for hidden cells are either not rendered at all or are detached from the DOM. Given that the columns collection does contains all the columns, the recommended approach is to use the following (below) code which will get you the visible ones (the hidden columns will always have their hidden property set to true):
$.grep($("#grid1").igGrid("option", "columns"), function (col) { return !col.hidden; });
For your request to allow a null value for PK, have you submitted this as a new product idea? If no, Infragistics invites you to submit this as a new product idea.
To suggest a new product idea you can do so by navigating to http://ideas.infragistics.com The steps are easy to do:
1. Create a new UserVoice account and log in to the Infragistics Product Ideas site at http://ideas.infragistics.com.
2. Navigate to the product / platform channel of your choice (e.g. WPF, Windows Forms, ASP.NET, HTML5 / Ignite UI, iOS / NucliOS, etc.)
3. Review the feature suggestions already posted by the community.
4. Vote for the features you’d like to see added to the product.
5. If the feature you’re looking for has not been posted, you can add your own product idea. Make sure to be specific and provide as much detail as possible. Explain the context in which a feature would be used, why it is needed, why it can’t be accomplished today, and who would benefit from it. You can even add screenshots to build a stronger case. Remember that for your suggestion to be successful, you need other members of the community to vote for it. Be convincing!
With this system, you are in the driver’s seat by submitting your product ideas. You can even track the progress of your ideas at any time, see how many votes it got, read comments from other developers in the community, and see if someone from the product team has additional questions for you.
Please let me know if you need any additional information regarding this matter.
Hi seang,
What seems to be the issue here is that the cellAt method is really working off thes that are rendered whereas columns are a completely separate entity that is not reflective of whatis generated. It is possible to have more columns because we need to the extra column objects whereas with s...we only render what is needed.
I agree that there is something here that we need to address and I am starting a conversation internally to see how best to resolve this.
Thank you Sean. I will return to you here on this forum thread once I have further details.