Text field has wrong value after error while editing

[errael]

To reproduce:

1. Modify demo schema supplier_data to add not NULL
status SMALLINT not NULL
2. Run Example 1, click on 1st records status field, cursor after 20, make sure entire field not selected
3. Enter backspace, see 2 in status field
4. Enter backspace, get dialog Null values are not allowed for STATUS, press OK
   Observe status field is blank
5. Click Next Record, then Prev Record
   Observe status field shows 2, which has been committed to the database.

Note: after the error popup, pressing undo puts 20 in the text field.

This is unexpected. At a minimum, after the error dialog, 2 should be shown in the text field.
Other possibilities include highlighting the field as an error, disabling all buttons until there's a valid entry.

This is related to #15; that issue is primarily about creating a new record.

[errael]

Tested with: 4.0.12

[bpangburn]

Testing EditErrReco with our software and the changes look good.

If I'm thinking about this correctly, similar changes may be needed for other components utilizing Document/DocumentListener. I think that adds SSTextArea and SSFormattedTextField.

There are some other .formatting components that use Document/DocumentListener, but they extend SSFormattedTextField.

I'm going to mark the PR as approved, but I won't merge it yet if you agree the additional changes are needed and you want them to go in #178 / EditErrReco.

[errael]

If I'm thinking about this correctly, similar changes may be needed for other components utilizing Document/DocumentListener. I think that adds SSTextArea and SSFormattedTextField.

Maybe, I'm not sure; I'll run some tests.

The changes for SSTextField are needed because the automatic numeric conversion might throw an exception. Oh, but wait, is it also needed if there's a data base error? I think I added a constraint to status so an error would be detected by the database and so be a different kind of exception; but I've forgotten what I learned from that.

There are maybe a few things involved that should be considered for a longer term strategy. For example

1. With the the numeric error, the problem is detected after one keystroke. An immediate error is easy for the user to deal with.
2. I think SSFormattedTextField keeps focus until the format is OK, so there's no "bad format" exception. You're stuck there until it passes muster.
3. SSTextArea allow a lot of typing, and I don't think there can be a bad format exception. Is there a case where SS flags only the last character as an error?

I may not be remembering/understanding some behavior, but I will check it out. What do you think?

And I don't particularly like the way that (2) works, keeping focus until the component is happy. I'd rather visibly mark that field/component as an error, let the user move on to other fields, then come back. But that's too much to do at this point. It requires some strategic design, may depend on an even more sophisticated decoration and per-component tracking.

There are some other .formatting components that use Document/DocumentListener, but they extend SSFormattedTextField.

[bpangburn]

Oh, but wait, is it also needed if there's a data base error?

Yes. The original example at the top of this issue results in:

WARN  com.nqadmin.swingset.utils.SSCommon.setBoundColumnText() - STATUS - Null Value Exception.
com.nqadmin.swingset.datasources.RowSetOps$SSSQLNullException: Null values are not allowed for this field.
{rest of trace redacted}

We normally would not have a 'not null' constraint on a multi-line database column (VARCHAR, LONGVARCHAR), but certainly possible (a 'required' notes field, a multi-line street address). I can't think of a great example of data validation paired with a SSTextArea where only the last character is flagged as an error.

I agree that SSFormattedText field putting the user on lock-down is frustrating from a user perspective. There are options, but as you indicate, we should probably come back to it after .formatting has stabilized.

[errael]

Oh, but wait, is it also needed if there's a data base error?

Yes. The original example at the top of this issue results in:

WARN  com.nqadmin.swingset.utils.SSCommon.setBoundColumnText() - STATUS - Null Value Exception.
com.nqadmin.swingset.datasources.RowSetOps$SSSQLNullException: Null values are not allowed for this field.
{rest of trace redacted}

Turns out this null violation for the status column is detected by SwingSet. In RowSetOps.updateColumnText() an empty string for an INTEGER column throws the exception if NOT NUL. I'm not sure what, if any, errors are detected by the JDBC driver by updateXxx(index, val).

The constraint violation CHECK (status <= 999) is detected when the commit button is pressed.

We normally would not have a 'not null' constraint on a multi-line database column (VARCHAR, LONGVARCHAR), but certainly possible (a 'required' notes field, a multi-line street address). I can't think of a great example of data validation paired with a SSTextArea where only the last character is flagged as an error.

I'm not sure NOT NULL matters much for CHAR base columns. RowSetOps.getColumnText()
converts a null to an empty string for these columns. And when writing, I don't think you can
generate a null from a text component.

Anyway, I think it's easy to use the magic document with SSTextArea, and I can set the column type to INTEGER to test it. But if it is always backed by a CHAR column, then it will never trigger.

LMK