FWD » Core Development » User Interface

1. The following code works as expected in OE, and causes the error number 4078 (Unable to set attribute SCREEN-VALUE...) in FWD:

DEF TEMP-TABLE tt FIELD f1 AS CHARACTER FORMAT "x(32)".
CREATE tt.

OPEN QUERY q FOR EACH tt.

DEFINE BROWSE brws
   QUERY q DISPLAY tt.f1
   ENABLE ALL
   WITH TITLE "Browse" 
   SIZE 70 BY 7.

DEF FRAME fr brws WITH TITLE "Frame" SIZE 70 BY 15 NO-LABELS.
ENABLE ALL WITH FRAME fr.

brws:SELECT-ROW(1).
tt.f1:SCREEN-VALUE IN BROWSE brws = "16122021".
WAIT-FOR CLOSE OF THIS-PROCEDURE.

The origin of the problem is in that the SELECT-ROW does not work correctly at the client side in case the first row is selected. The code in the Browse class:

public boolean selectRow(int rowIndex)
{
   int row = getCachedRowNumber(rowIndex);
   if (isSelectionMultiple())
   {
      ...
   }
   else if (getCurrentRow() != row)
            ^^^^^^^^^^^^^^^^^^^^^^
   {
      ...
      setCurrentRow(row);
      ...
   }

does nothing in the case getCurrentRow() == row, which is the case just after the browse has been created, and setCurrentRow() is not called, and
the currRowSelected flag remains false.

2. Another difference: OE displays error 382 (FWD displays error 4078).

FWD throws the correct error 382 first, but this exception is not displayed as alert box.

Stanislav Lomany wrote:

Vladimir, this is caused by your recent change where exception is caught in GenericWidget and therefore not handled in BrowseColumnWidget. I extracted error handling to a separate function.

This change of yours looks artificial and hence a bit suspicious to me. I will see at it more thoroughly on Monday.

Vladimir Tsichevski wrote:

Stanislav Lomany wrote:

Vladimir, this is caused by your recent change where exception is caught in GenericWidget and therefore not handled in BrowseColumnWidget. I extracted error handling to a separate function.

This change of yours looks artificial and hence a bit suspicious to me. I will see at it more thoroughly on Monday.

You added the setScreenValueNoErrorHandling() method to artificially change the error handling control flow. I did not analyze all the implications, but may be, it would be better to handle errors where they arise: use ErrorManager.recordOrThrowError(382, ...) methods instead of just throwing the exception with throw new ErrorConditionException(382, "")?

may be, it would be better to handle errors where they arise: use ErrorManager.recordOrThrowError(382, ...) methods instead of just throwing the exception with throw new ErrorConditionException(382, "")?

That's just a convenient way to return control to server and write to server log. I'm not sure if ever use ErrorManager.recordOrThrowError on the client side.

I thought you would ask if we want to handle error 382 in GenericWidget (that may be an option).

Greg, please review 3821c rev 12267 to close this off.

That's just a convenient way to return control to server and write to server log. I'm not sure if ever use ErrorManager.recordOrThrowError on the client side.

Correct, we generally should not use ErrorManager.recordOrThrowError() on the client side. In addition to the issue with the server.log we have the problem with recording error state in the ERROR-STATUS handle. Although the RemoteErrorData does allow some of the state to be redirected to the server, this is inefficient (very slow) and it may not be complete.

Throwing real exceptions on the clinet shifts the control flow to the server, where the error handling is properly managed.