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

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

Roland,

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

Seb

Thanks Reuben, No I wasn't aware of that openFiles frontcall; I will pick this up on Monday but that looks perfect for what I need.

Have a good weekend.
Regards
Sean

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

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







 

  

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

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

[in your example code]

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

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