Changes

ProposalField: fix custom text in touch mode while error status present

Problem: If there is an error status present on the proposal field it
will be mirrored to the field in the touch popup. When the value of the
field in the touch popup changes, its error status is cleared. If this
value change happens because a custom text was entered, the error status
of the main proposal field will not be cleared. The SmartFieldAdapter
will not send the value to the server if there is an error status
present on the field. Therefore, the value in the model on the server
never changes.

This problem only occurs in the touch mode when entering a custom text.
When a lookup row is selected, the error status will always be cleared
regardless of the touch mode. If a custom text is entered in the desktop
mode, the error status will also be cleared.

Therefore, add the error status to the properties that are copied from
the touch popups field to the main proposal field. This leads to the
error status being cleared for all different ways the proposal fields
value can be changed and therefore, the new value will be sent to the
server, where it is updated in the model.

369873
 (commit: 92ecdd3)

ProposalField: always send the correct acceptInput event

The ProposalField can accept customText, i.e. a value with no
corresponding lookupRow. If the triggered acceptInput-event of the
ProposalField is marked with acceptByLookupRow the event sent to the
server contains a lookupRow property. Ensure that there is no lookupRow
property in an event for a custom text in order to make handling of a
lookupRow property with value null obsolete.

369873
 (commit: 4846ee5)

ProposalField: fix validation errors

If a potential value that is not accepted by the validator of a
ProposalField is passed to the field, the display text needs to change
while the value stays the same.
If this value comes from a selected lookupRow, the lookupRow will be set
and therefore, the formatting needs to consider it.
If this value comes from a touch popup, there are several things that
need to be considered:
* The lookupRow must not trigger any value changed logic, as setting a
  value that does not pass validation will reset the value to the
  previous one. Otherwise, if the new lookupRow is null it will set the
  value of the field to null and therefore the reset-logic after a
  failed validation resets the value to null as the former value is
  already lost.
* The displayText needs to be set without exception, as it can differ
  from the value. Consider the value 'info' for which a validator adds
  an error status with severity info and another value 'throw' for which
  the validation fails. Switching between these two values will never
  change the value, it will always stay 'info'. But what needs to change
  are the displayText and the error status. Therefore, the value needs
  to be set again when switching from 'throw' back to 'info' as the
  validator needs to run in order to add the info-error status. The
  displayText needs to be set to support the 'info'>'throw' case as
  setting a value 'throw' will never change the displayText it needs to
  be transferred explicitly from the touch popup.
* The value needs to be set without exception, even if it is identical
  to the current value. See example for displayText.
To support the 'throw' > 'info' case from the previous example correctly
for Scout Classic, an input needs to be accepted and all listeners need
to be informed if the search text changed to the text of the current
lookupRow. Consider the previous example and the inputs "lookup 'info'"
> "lookup 'throw'" > "write 'info'". While writing 'info', the 'info'
lookupRow is still present and the searchText changes from 'throw' to
'info' and therefore, the listener in the adapter needs to be triggered
in order to validate 'info' again on the ui server.

369873
 (commit: 6f89d63)

ProposalField: fix open and close touch popup multiple times

If the touch popup of a SmartField or ProposalField is opened and closed
multiple times without changing the value, the properties value,
displayText, errorStatus and lookupRow of the corresponding field need
to stay unchanged. These properties are copied from the original field
to the field in the touch popup. Therefore, save the initial state of
these properties and compare them before closing the popup to detect
whether the popup was changed or not.
It is not sufficient to mark the field in the touch popup as saved and
check if it was touched before closing as there might be validators that
throw exceptions on some values. Consider two values 'ok' and 'error'
and a validator that throws an error if 'error' is selected. When
switching between these two the value of the ProposalField will always
be 'ok' but the displayText will change. Marking the field in the touch
popup as saved and checking if it was touched will only consider the
value which has not changed in this example and there would be no update
of the original field and the resulting errorStatus will be
inconsistent.

369873
 (commit: 2797744)