[Isomorphic]

A fix actually just went into mainline. We'll be getting it ported to 12.0 in the next couple of days, so we'll follow up then

[Blama]

Hi Isomorphic,

testing with SNAPSHOT_v12.1d_2018-06-15, I noticed that it changed to the better, but it is still not good.
If you fix the last error a row has (the 1st if it has one, the 2nd, if it has two, ...), the Prev/Next buttons will still activate editing of that last-fixed-error-cell.

Also, if you just keep clicking "Next", until it gets deactivated, and then click outside, "Next" is activated again.
This does not match the behavior of "Prev", which is disabled on start. Also, if you enter the ListGrid in the middle and then click "Prev" until it gets disabled and then click outside, it stays disabled (as expected). This is not happening for "Next".

Best regards
Blama

[Blama]

Hi Isomorphic,

can you reproduce the issues I had here? Did you do any further changes? Please note that this is not working as expected also in 12.0p.
I did not switch yet, but will do so eventually.

Best regards
Blama

[Blama]

Hi Isomorphic,

any update on this one?

Best regards
Blama

[Isomorphic]

Sorry for the silence - it's been passed to a developer to look at but no update yet. We'll follow up soon

[Isomorphic]

Hi Blama

If you fix the last error a row has (the 1st if it has one, the 2nd, if it has two, ...), the Prev/Next buttons will still activate editing of that last-fixed-error-cell.

This could happen on the first or last row and was actually a side effect of the asynchronous server-side validation on one of the fields here not "playing nicely" with the other fields. We've made a change which should address this - will be present in the next nightly build.

Also, if you just keep clicking "Next", until it gets deactivated, and then click outside, "Next" is activated again.
This does not match the behavior of "Prev", which is disabled on start. Also, if you enter the ListGrid in the middle and then click "Prev" until it gets disabled and then click outside, it stays disabled (as expected). This is not happening for "Next".

This is actually expected behavior. When you are actively editing a cell, the "Prev" button will move you to the previous error (in the same row, or an earlier row), or be disabled if this is the first error on the grid.
The "Next" button will move you to the next error, or be disabled if this is the last error on the grid.
When you are not actively editing a cell, the current selected row is considered the "starting point" for editing. So the "Next" button will start editing the first error it finds in that row, or in subsequent rows (or be disabled if there are none), and the "Prev" button will start editing the last error in a previous row (or be disabled if there is none).

So if you move forward through the errors using the "next" button, when you get to the end and dismiss editing, the last row you were editing presumably contains an error (the last error on the grid), and since this row is selected, hitting "Next" will start editing that cell. Conversely, if moving backwards through the grid, when you get to the first error and dismiss the editor, the selected row contains the first error in the grid - there are no earlier errors, so "Previous" will be disabled

WRT 12.0 - we are porting the changes to 12.0 today, so you should be able to pick up the fixes in both branches in the next nightly build

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

the error handling is working good now IMHO in SNAPSHOT_v12.1d_2018-08-04, thanks a lot. I'll retest 12.0 as soon as a new build is available.
I found another (ListGrid related most likely) issue, though. I'll create another thread for this one.

Best regards
Blama