I'm having trouble getting saveChangesErrorHandler to be called when (for example) the I send a bad HTTP PUT request to the server.
features : [ { name : 'Updating', editMode: "cell", startEditTriggers: "dblclick,F2", showDoneCancelButtons : true, saveChangesErrorHandler : function (jqXHR, textStatus, errorThrown) { alert("An error occurred while saving the changes: " + textStatus); }, saveChangesSuccessHandler : function (data) { alert("Changes saved."); },
<etc>
I see an alert from saveChangesSuccessHandler after a successful save, but never from the error handler. Similarly, a breakpoint in the error handler is never hit.
I tried pasting the handlers above to a sample project that Infragistics sent me for an unrelated issue, and got the exact same behavior. So it's presumably something silly like a typo, but I compared the lines to the docs and I'm not seeing the problem.
Thanks!
Hello Matthew Diamond,
saveChangesErrorHandler is used when an error occurs during the saving of the data.
An option in the igGrid "updatingUrl" can specify an ActionResult which handles the processing(saving) the data on the server. And saveChangesErrorHandler will be fired if an error occurs during that handling. So if you want to trigger that event you can try throwing an error in the updatingUrl ActionResult.
If you want to fire some custom errors you can use this approach(http://stackoverflow.com/a/4235168)
Sorry, I'm not following. I think I didn't give you enough information.
I am using the grid on a jQuery page and sending updates to the server using the restSettings feature. (This is not ASP.NET.) If the server throws any kind of error, e.g. 500 Bad Request, neither the saveChangesErrorHandler nor saveChangesSuccessHandler get called. I also tried putting a try/catch around the saveChanges call, but no exception is thrown. As far as I can tell the error is logged and swallowed by the grid.
So I'm looking for a way to detect that an error was returned by the RESTful service, and to get the error details. The Stack Overflow seems to require passing back a successful result instead of an error; the error would instead be in the payload of the message. I don't think this technique applies for a RESTful service that uses the standard HTTP error codes.
I hope this clarifies my issue. If I misunderstood your suggestion please let me know. Thanks!