I have recently started using GXT 3.0.1 and I'm trying to edit a grid where values entered into each column can affect other columns and data must be validated. I have tried both GridInlineEditing and GridRowEditing, but each are causing issues.
I need to calculate values based on the value of a cell. So let's say I update cell A, then cell B should update to reflect this value. Similarly for editing cell B, then cell A should update. As well as this, I need to validate my changes before submitting.
GridInlineEditing - CompleteEditEvent fires each time tab is pressed and I can work out which values have changed based on storing previous value and lookng at Store.Record.getChange, so this works. However, validation simply doesn't work in 3.0.1 (see: http://www.sencha.com/forum/showthread.php?255907-Validation-in-GridInlineEditing) and I cannot upgrade, so I hit a dead end here.
GridRowEditing - CompleteEditEvent only fires once entire row has been updated, so now validation is works, however, I cannot calculate column B after column A updated due to the event firing once.
Has anyone faced this same issue and found a solution?
Many thanks in adavnce.
Stephen
I have recently started using GXT 3.0.1
GXT 3.0.1 was released over a year and a half ago, and two weeks ago 3.1.0 went out - try moving to GXT 3.1.0. In addition to many bug fixes, both row and inline editing now support field validation. If you cannot upgrade to 3.1.0, these changes were added in 3.0.5 or 6, see if you can upgrade at least that far. Knowing why you can't upgrade to either version will make it easier to make other suggestions - if you are relying on behavior that was fixed as part of another bug, it might make it contradictory for you to want bugfixes, but not all bug fixes.
If all else fails, perhaps look into extending the grid editing that you are using, consider overriding completeEditing or doCompleteEditing to modify the behavior directly, either by copying code from the newer releases, or by emulating the validation behavior through your own tooltip or alert, and not finishing the 'complete' code.
Related
I'm trying to turn on the sort feature on one of my grids. I've cloned the examples in the Kendo doc, but it never becomes available.
Does it have to be set before or after filters and/or columns? I found when modifying the filters, it had to be done before setting the columns, otherwise it would go with the default.
Thanks
As per usual, I post a question, and thirty seconds later I found the answer.
The developer who wrote the original code broke everything into functions, and then built the kendo portion from them. He never added the sortable option to the final build!
've just tried giving the latest release of Kendo UI a spin, but it seems something has broken when using a DropDownList in a custom popup editor.
If the dataSource of the DropDownList is set to a JavaScript array or object, the selected value does not update the Grid model.
DropDownLists that have a remote dataSource with dataTextField and dataValueField configured are working okay.
Basically, code that worked perfectly with the 2014.3.1316 release is not working with the 2015.1.318 release (no errors are reported in Chrome's console).
Can somebody please confirm that this is a bug with the new release, or is there something else I need to be aware of?
EDIT: This is seems to be affecting all DropDownLists. The selected item is not updating the model immediately -- only when the record is saved.
I've knocked together a simple Fiddle to demonstrate the issue. With the previous version, selecting an item updates the Grid's model immediately and set's dirty to true. With the new version, the Grid's model isn't updated (at least not immediately).
The described issue is a known bug in Q1 2015 - BUG 623.
It is addressed in the latest internal builds and the upcoming service pack, that will be released till the end of week, will include the fix (and many more)
I am afraid that there is no simple workaround, as the widget just sets its "_old" value to the new one on first select. Hence the change event will not be raised. The only feasible solution is to upgrade to a newer version of Kendo UI.
When it comes to the dropdownlist and multiselect controls they have changed a lot to allow the new grouping and virtualization features to work. (having been a victim of this change as well - I'm still trying to fix my code at the minute)
I have updated your fiddle with a possible solution for what you want to achieve Update with Change Event added
I have basically added this function for you:
function changeCategory(e)
{
$('#log2').text('This should be the ID of the category you changed too: '+
e.sender.value());
}
but for more information on this change you can look here:
Changes to Kendo UI Q1 2015
EDIT:
Also if my memory is correct I think the select event is fired before the change event so that will always show the previous value and not the new value that has been selected and when you click update the grid is updating as expected from what I can see.
just try to specify a defaultValue in your schema model definition to CategoryID, i think this would be a better solution, couse this bug occurs only when the value is empty
The Changes to Kendo UI Q1 2015 page doesn't directly mention the change in behavior described, but it's likely to be caused by the substantial changes to the DropDownList widget.
There's a pretty simple workaround, but I suspect it shouldn't be necessary and will be 'fixed' at some point.
To emulate the old behavior you just need to manually set the model field that's supposed to be updated immediately. So in the select event add something like...
model.set('CategoryID', dataItem.CategoryID);
Updated Fiddle. Without doing this, any dependent methods will use the original or old value, which is simply not right (hence, I suspect it'll be fixed).
I also experienced the problem with dropdown lists with the 2015.1.318 release.
In the latest release, 2015.1.327, this seems to be fixed.
We're currently using Kendo version 2012.2.710.340, and I know that this version had an issue with null date columns being displayed as 'null'. I know also know that this can be worked around using a template with a condition to check for null.
However, is there any global fix for this? We use numerous grids throughout our application, and I don't want to have to add a fix for every single column we bind in each grid.
Alternatively, is this fixed in newer builds? I remember seeinga forum post saying it would appear in the next release a few months ago, but can't seem to find any reference to it now.
Yes, this is fixed - null is no longer displayed. Empty string is displayed instead. Try a newer version.
I have a grid that is populated by a JSON response (MVC3 controller) that has a userData component for some additional data for grid captions, etc. All that works just fine. I recently switched the the grid's data loading to "loadonce: true" as in working with larger grid results sets, I wanted client-side sorting and filtering. All that works good. BUT, I was surprised that the userData got wiped the first time I clicked any column for sorting. If I turn off loadonce, userData is fine, but it is of course going back to the server each time. The items that make use of the userData fire on gridcomplete and are now coming back "undefined" after a sort (and probably anything that reloads the grid). Any thoughts why this might be happening? Oh yeah, I also noticed that clicking a column sort wiped out any multiselections (perhaps related to the same culprit?).
Thanks,
Mark
You are right. +1 from me. It's a jqGrid bug. Inside of internal addLocalData method after the line 1527 of the file grid.base.js of jqGrid 4.1.2 or after the 1532 of jquery.jqGrid.src.js (you can get modified version from here) one should add the following line
retresult[ts.p.localReader.userdata] = ts.p.userData;
It will fix the problem. I posted the corresponding bug report here.
When I open form to edit values:
It doesn't change form values when I navigate with <> buttons
It opens New form with same values as first edited row, and when I click "Submit", it overwrites that row instead of creating a new item
When I click to edit another row, it always shows the form values for the first edited row – i.e. if I click New first and then edit row, it shows empty form.
So, in short, the first time form opens, the values are "stuck" whatever row I open later.
What can cause this? I remember it used to work OK some time ago.
UPDATE:
No with recreateForm I don't have this issue (I use it as temporary workaround).
Hm, I can reproduce this on jqGrid example, but not on Live Manipulation - on New in Version 3.7, Add/edit/delete on local data:
Click any row and edit it (open form)
Close form
Select any other row and click edit - form shows incorrect values (from the row that was opened first)
Click Add new row button in toolbar - form shows same values - which is very convenient, usually new rows are "almost" same - if only it would add new row, not update the existing one!
Of course in live demo Submit doesn't do that (it doesn't seem to work at all) but except for this symptoms are same.
Also <> buttons do not change data in form, though they change selected row - but from what I remember previously it used to update form values also to match selected row.
Probably you should post the description of your bug with "New in Version 3.7", "Add/edit/delete" as a bug in the in trirand forum.
The problem is that the bug exist in very special environment/data/settings. For example I tested my old local edit example modified to jqGrid 3.8.1 or in 3.7.2 and can not reproduce the problem which you describes. So you can use my examples as a template could it helps you.
Moreover in all examples which I use for real projects I use always parameter recreateForm:true. If you don't use it jqGrid not create a form, but try to use an existing with other data. It works in a lot of cases wrong. For example if you use any dataInit functions they will be called only once during creating of the form, which can make very strange affects. If you use edittype: 'custom' the usage of recreateForm:true is really mandatory (see this). So I recommended many times all people to use
jQuery.extend(jQuery.jgrid.edit, {recreateForm: true});
to set recreateForm: true as your default settings. You could save many hours or days of debugging of some strange effects in your edit/add dialogs.