FWD » Core Development » User Interface

When calling view on a frame, or change it's visibility in FWD some of the fill-ins in the frame shows a default value while in 4GL the screen-value shows as empty before using the widgets in a display statement. It appears this is the case for numeric and logical data types only.

To test this run ui/frame/test_view_fillins.p in testcases project.

Hynek: Please review and merge to 3821c if it is OK.

Greg Shah wrote:

Hynek: Please review and merge to 3821c if it is OK.

Marian, the change also affects other use cases than only VIEW or visibility change. For example tree editor activation, text input dialog (TC.runTextInput), color chooser dialog, directory and file dialogs. Shouldn't the change be targeted closer to the VIEW statement and visibility change implementations?

Hynek Cihlar wrote:

Marian, the change also affects other use cases than only VIEW or visibility change. For example tree editor activation, text input dialog (TC.runTextInput), color chooser dialog, directory and file dialogs. Shouldn't the change be targeted closer to the VIEW statement and visibility change implementations?

Hynek Cihlar wrote:

Greg Shah wrote:

Hynek: Please review and merge to 3821c if it is OK.

Marian, the change also affects other use cases than only VIEW or visibility change. For example tree editor activation, text input dialog (TC.runTextInput), color chooser dialog, directory and file dialogs. Shouldn't the change be targeted closer to the VIEW statement and visibility change implementations?

Hynek, the display purpose is to move data from underlying variable to the screen (this is what 4GL does and given the javadoc of the method looks like FWD is using it for the same purpose). Normally this should not be called when data type or format is being set, setValue looks to me the only valid place when the display should be called. But, that being said, the size of the fill-in is affected by the data type (default format) or the custom format set for the widget so taking out the call to display isn't possible. However the screen-value should be empty before the actual display, as it is now for numeric and logical variables that have default values the screen-value on the client side is not empty - 0 for numeric, no for logical and this is what is being displayed in UI. If we message out screen-value for those widgets it shows empty string but again, this is not what the UI shows.

So, I do not see what could be done in the view statement to address this but I might be wrong and there could be better way... that feels like a hack anyway.

Normally this should not be called when data type or format is being set

The DISPLAY <expr> format "<fmt>" @ base_field syntax is an example of the data type and format changing.

Greg Shah wrote:

Normally this should not be called when data type or format is being set

The DISPLAY <expr> format "<fmt>" @ base_field syntax is an example of the data type and format changing.

Yes but then this does involve the display even if before actual display the format is being changed.

ON CHOOSE OF BUTTON-2 IN FRAME DEFAULT-FRAME /* Button 2 */
DO:
    FILL-IN-Default = 'extravagantza'.
    display FILL-IN-Default format 'x(10)' with frame default-frame.

    message FILL-IN-Default:format view-as alert-box.
END.

This displays only first 10 characters ('extravagan') and do change the fill-in format, but then when only the format is changed then there is no display - simply the current screen-value is being formatted as needed.

ON CHOOSE OF BUTTON-1 IN FRAME DEFAULT-FRAME /* Button 1 */
DO:
    FILL-IN-Default = 'newvalue'.
    FILL-IN-Default:format = 'x(6)'.
END.

This changes the screen-value to 'extrav' not 'newval' so really there is no data update from variable to screen-value hence no display.

As for data type, this can't be set once the widget was realized so no real display needed - normally all the widget needs to know is the screen width it will need based on data-type and format, the 'presentation' used for data binding can be set when the data type is being defined but it definitively must not have any value (if display is still being used).

Hynek Cihlar wrote:

Greg Shah wrote:

Hynek: Please review and merge to 3821c if it is OK.

Marian, the change also affects other use cases than only VIEW or visibility change. For example tree editor activation, text input dialog (TC.runTextInput), color chooser dialog, directory and file dialogs. Shouldn't the change be targeted closer to the VIEW statement and visibility change implementations?

I tested the test cases and I didn't find any issues. So, Greg, if you agree I will merge the changes in 3821c.

Yes, go ahead.