next »

[Roland W.]

Hello everyone,

Is there a reason why the DISPLAY ARRAY/AT/TO/BY NAME statements do not allow a STYLE to be specified for the attributes (https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_record_display_DISPLAY_BY_NAME.html)?
In contrast to MESSAGE (https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_message_display_MESSAGE.html) and ERROR (https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_message_display_ERROR.html), only the TTY attributes can be used here.
So if I want to display an element differently (e.g. to indicate an error), I only have the option of either specifying this directly in the form or manipulating the AUI tree directly.
Wouldn't it be more practical if this could also be specified via a STYLE attribute in future instead of being restricted to the TTY attributes? Or is there another option that I have missed?

Kind regards
Roland

[Sebastien F.]

Hello Roland,

Did you consider using DIALOG.setArrayAttributes(), to put specific colors on individual cells?

https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_prog_dialogs_cell_attr.html

There was once a request to specify a style for each cell but I think using simple colors and TTY attributes like reverse is sufficient.

We are using this in the FGLSQLDEBUG viewer, see screenshot here:

https://github.com/FourjsGenero/tool_fglsqldebug

Seb

[Roland W.]

Hello Sebastien,

I'm aware of the setArrayAttributes() function, although this only works for arrays/tables but not for single elements such as Edit fields.
Funnily enough, in your example code, the AUI tree is also manipulated directly to assign a style to an element. So there does seem to be a need for a simpler solution.

Apart from that, I always found the possibility of specifying the attributes via the setArrayAttributes() and setCellAttributes() functions unsatisfactory because you have to define the array structure again separately. If you then add or delete a new column, you always have to bear in mind that you also have to adapt the second array. From my kind of view it would be more practical to be able to specify the attributes directly when defining the array, similar to how it is already possible to specify the attributes for JSON or XML syntax (https://4js.com/online_documentation/fjs-fgl-manual-html/index.html#fgl-topics/c_fgl_Arrays_attributes.html and https://4js.com/online_documentation/fjs-fgl-manual-html/index.html#fgl-topics/c_fgl_variables_attributes.html).

Kind regards
Roland

[Sebastien F.]

Roland,

Sorry if DIALOG.setArrayAttributes() does not satisfy your needs.
I am using this in many Genero programs, and I think this is a great feature easy to program.

Funnily enough, in your example code, the AUI tree is also manipulated directly to assign a style to an element

???
What code example are you referring to?
I see no direct AUI tree manipulation.
What do you mean?

Seb

[Roland W.]

Sebastien,

there's a function style_define() in fglsqldebug.4gl (https://github.com/FourjsGenero/tool_fglsqldebug/blob/master/fglsqldebug.4gl) to apply a generic style to a Group element.

Anyway, maybe you could think of adding the STYLE=... syntax to the ATTRIBUTES section for display elements.

Kind regards
Roland

[Sebastien F.]

Oh I see what you mean:

Code

FUNCTION define_collapsible_group_style()
    DEFINE attdefs DICTIONARY OF STRING
    LET attdefs["collapsible"] = "yes"
    LET attdefs["backgroundColor"] = "lightBlue"
    CALL style_define("Group.collapsible", attdefs)
END FUNCTION
 

Yes, this is direct AUI tree manipulation, to create a new style for groups, from the program instead of adding a .4st file to the tool.
Since .4st style files have no inheritance, if you want to use the latest changes in FGLDIR/lib/default.4st, this is the best solution I found.

Regarding style usage in DISPLAY ARRAY to decorate individual cells with setArrayAttributes(), we have the request https://4js.com/support/issue/?id=FGL-01470#startissue, to use styles instead of simple colors, but that is rejected, and anyway would not help you since you don't like setArrayAttributes().

I do not see how DISPLAY ARRAY ... ATTRIBUTES(STYLE=...) would help to decorate individual cells.
Are you asking for a way to defined a global style that would apply to all data rows in the TABLE?
This is possible by specifying a STYLE in the TABLE definition in the .per.
I am not sure to understand your request.

Seb

[Reuben B.]

Roland,

This was requested way back in 2005 ! See https://4js.com/support/issue/?id=FGL-03783
and in 2006 for the array case https://4js.com/support/issue/?id=FGL-1470

These can always be revisited but need to have the appropriate level of demand captured and would probably need to add a compelling argument that we need to take into account now.

So if I want to display an element differently (e.g. to indicate an error), I only have the option of either specifying this directly in the form or manipulating the AUI tree directly.
Wouldn't it be more practical if this could also be specified via a STYLE attribute in future instead of being restricted to the TTY attributes? Or is there another option that I have missed?

For the non-array case, you do have the ui.Form.setFieldStyle method https://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_ClassForm_setFieldStyle.html which I suspect you have missed.

So something like ...

Code

-- If > 80, display as red, if > 60 display as orange, otherwise display as green
DISPLAY BY NAME rec.value
CALL f.setFieldStyle("value", IIF(rec.value > 80, "red", IIF (rec.value > 60, "orange", "green")))
 

There is a weakness in the setFieldStyle method if you are in the habit of specifying multiple styles for individual fields.  You may want to write your own library function to add / remove styles to the space delimited list of styles. https://github.com/FourjsGenero/fgl_auitree/blob/master/auitree.4gl#L216-L255




Reuben







 

  

[Roland W.]

Reuben,

OK, that's what I have missed. However, why not just adding the STYLE=... to the ATTRIBUTES section, which in my opition, would make sense for single DISPLAY BY NAME statements. Depending on how many elements are displayed with DISPLAY BY NAME statement, this would save multiple calls to setFieldStyle() or setElementStyle() for each individual element. I see that the request https://4js.com/support/issue/FGL-03783 has been rejected, too bad.

Sorry Sebastien, I was mainly referring to the display of individual edit elements, not to the display of a complete array/table.

So, I guess I have to use setFieldStyle() or setElementStyle() to decorate single Edit fields. It was at least worth a try.

Kind regards
Roland

[Sebastien F.]

Roland,

I do never use DISPLAY BY NAME, because I use the UNBUFFERED attribute in all my dialogs.

Seb

[Roland W.]

Sebastien,

despite calling ui.dialog.setDefaultNnbuffered(true) and setting the UNBUFFERED attribute in the INPUT BY NAME statement, the automatic display of variables does not seem to work correctly or does this only apply to variables defined in an INPUT BY NAME?
I have defined some display fields in a form that contain values but are not explicitly displayed. If I omit the instruction DISPLAY BY NAME p_var, the value is not displayed. This is the reason why I use DISPLAY BY NAME in many cases, just to make sure that all values are displayed correctly. Unfortunately I haven't found out exactly why this is the case. Maybe I should open a support case for this.

Kind regards
Roland

[Sebastien F.]

Hello Roland,

Obviously, automatic variable / form field sync with UNBUFFERED attribute only concerns variables bound to form fields in your current dialog instruction.

You must append the variables to the INPUT BY NAME instruction to get this automatic sync.

Code

INPUT BY NAME rec_customer.*, p_var ATTRIBUTES(UNBUFFERED, WITHOUT DEFAULTS)
   ...
   AFTER FIELD cust_name
        LET p_var = "[",rec.cust_name,"]"
        -- no need for DISPLAY BY NAME disp_var or DISPLAY disp_var1 TO field
 

The corresponding form fields should be read-only (NOENTRY), or you should use non-editable form fields like LABEL.

But understand: You are not forced to review all your code to use this pattern. My suggestion about using UNBUFFERED was mainly for variables/form fields that are already part of your INPUT BY NAME.

Seb

[Roland W.]

Sebastien,

OK, thanks for clarification. I'll try to adapt my code accordingly in the future.

Kind regards
Roland

[Reuben B.]

Roland,

Have a read of https://4js.com/ask-reuben/ig-89/ for a discussion on UNBUFFERED.  Note the point "What you may also find is that you add fields to the dialog statement even though they are NOENTRY". 

A typical scenario is you have

Title (Label).     Code. (ButtonEdit).   Description (Label)

you might add the Description field to the INPUT statement so that any change in value of Description is reflected in the front-end without an explicit DISPLAY being required

Reuben