Hi Tsanna,

I was able to put together an example for your and i've attached it. It appears that this is happening due to the validation. In the attached example, edit the first row, then edit the numeric amount. The Done button is disabled and there is no way to enable it. If you set the NumericEditorOptions.MinDecimals field, then the validation appears to fail without even entering a value (e.g. click the first Filed0 cell and then click the Field1 cell and the Done button is disabled).

As a workaround in our production solution, we will just disabled validation for now.

Thanks,

Paul

Hi Tsanna,

I think I see why you are unable to duplicate the disabled Done button. Your loop in ProductList isn't changing the readOnly attribute, so some of the JQuery we put in is not getting called. In the ProductList class, change

product.Field1ReadOnly = false;
product.Field2ReadOnly = true;

to something like this:

product.Field1ReadOnly = i % 1 == 0;
product.Field2ReadOnly = i % 1 == 1;

Thanks,

Paul

Ok, I changed the code, but still cannot reproduce your issue with the disabled Done button.

Sorry, I sent the wrong code. Instead change it to the following:

product.Field1ReadOnly = i % 2 == 0;
product.Field2ReadOnly = i % 2 == 1;

After doing this, click on row #1, Field2. Then click on row #2, Field1. Change the value in Field1 and the Done button will remain disabled.

Thanks,

Paul

Hello Paul,

There is quite a bit to clarify on regarding the case and why your original solution stopped working after the update. I will add another reply about this tomorrow. In case you are blocked I am only attaching the solution to your requirements for now so you get it more quickly.

Attached you will find the Index.chtml file with the JS code that you need. In addition please don't set the editors readOnly property through the MVC helpers. Updating has its own readOnly implementation that's separate and works better in the context of the grid. Don't set that either - the solution will only care about cancelling the editCellStarting event instead of juggling the readOnly properties.

Best regards,

Stamen Stoychev

Hi Stamen,

Thanks for the update. Everything is working as expected in the test solution after adding your scripts. We'll update this in our production product and let you know if we have any more issues.

One minor thing we encountered is that setting ExcelNavigationMode to true in the GridUpdating feature does not appear to work anymore. When Enter is pressed after editing a row, the next row is not edited as expected. This is not a big deal and we can live without this feature if there is not an easy way to fix this.

Also, we were able to get the original solution working again after uninstalling and reinstalling Microsoft.AspNet.Mvc.

Thanks,

Paul

Thanks Stamen, this works nicely.

Also, thanks for your very detailed analysis on this issue. This information is very helpful.

Thanks,

Paul

Hello Paul,

I am sorry, I didn't take navigation into account with my solution. The issue comes from the code responsible to focus the read-write editor when the user clicks the read-only one. Please, try to replace the editRowStarting handler with this:

"iggridupdatingeditrowstarting": function (evt, ui) {
    var rec = ui.owner.grid.findRecordByKey(ui.rowID), arid, target, td;
    readOnly.Field1 = rec.Field1ReadOnly;
    readOnly.Field2 = rec.Field2ReadOnly;
    // store the clicked cell's key
    target = $(evt.originalEvent.target);
    td = target.closest("td");
    if (td.length) {
        aria = $(evt.originalEvent.target).closest("td").attr("aria-describedby");
        clickedColumn = aria.substring(aria.indexOf("_") + 1);
    } else {
        clickedColumn = target.closest(".ui-igedit").igEditorFilter("option", "provider").columnKey;
    }
}

Please, have in mind that excelNavigationMode is not really aimed at "row" edit mode so you won't get the full experience using them in conjunction. But navigation should start working using the updated code at least.

Regarding the clarification I promised, one important note with your original solution was that essentially you were doing what I am doing with mine. This is because targeting the grid and getting the updating options from there (through the "features" array) and editing them was essentially just caching the changes for your personal use in the other handlers. Neither the grid nor updating would use or acknowledge changes made in this way. I just simplified the whole ordeal by caching in a separate object and not caring about getting options objects from features.

Generally speaking, changing options for widgets should be done through a call like this: $(selector).[widget]("option", [option-name], [new-value]).This ensures the option change is handled by the widget so that internal processes can be run to ensure the option change doesn't break the widget's state. This is basically what Tsanna suggested in her first reply and would make swapping the readOnly properties consistent for Updating as well. What wasn't taken into account was that the grid implements strict ARIA specification and each read-only cell is properly marked as one through an "aria-readonly" attribute. For performance reasons this is done by rendering each row anew. With virtualization, however, it would render them from the start as there is currently no clean, built-in functionality to restore scroll positioning and therefore would make restoring the correct edit  mode impossible.

This prompted me to redo your original solution cancelling the editCellStarting event, just simpler and with one caveat - editors that are marked as required ("Field2" in your sample) need to get a non-null value as Updating resets each editor's value to null between edits but only remedies that for the ones that enter edit mode. This leaves the editor for "Field2" to have a value "null" but participate in validation regardless of the end-users inability to enter value for it leaving the row in an "invalid" state indefinitely.

In summary your use case is certainly not well supported by the product with issues that are impossible for an user to properly find and resolve with straightforward workarounds. I'll keep this open for a while so that I can identify how to improve on it ideally making such per-row read-only setup not only work out of the box but also be consistent with the ARIA specifications.

Best regards,

Stamen Stoychev