next »

[Andrew C.]

just putting them out there...

we've derived great value from extending the syntax of tables with:

Extension 1

Code

table (lines=10)
{
   Col1    Col2    .....
  [A1    ][A2     ] ....
}
end

The pre-processor replicates the last line N times from the lines= attribute. This saves effort when editing and viewing a table.

Extension 2

Code

table (stacked, lines=10)
{
  Col 1   [A1      ]
  Col 2   [A2      ]
  .....
}
end

The stacked attribute tells the pre-processor to read the table as a list of column titles and column definitions. After collecting the labels and fields, it re-organises it into the .per as a proper table accepted by fglform, taking care of spaces where necessary. The label is optional, and the list of columns allowed may have a few fields separated by the usual | symbol. Beyond that is not allowed by the pre-processor. Our programmers line up the [ by convention but it's not required.

When using stacked, the lines attribute is needed by our system so it knows how many lines to replicate, but it would probably make more sense to rely on the array count given in the screen record definition in the INSTRUCTIONS section.

Posting this because I thought it might inspire a simple extension to .per files that everyone would enjoy.

Cheers

[Rene S.]

Hello,
Extension 1: since lines is a valid table attribute in the ATTRIBUTES section it should be valid for an explicit table container.
Confirmed, simple to implement.

Extension 2: yes, simplifies reading a form file. Especially when forcing source files to have a limited number of columns. (I'm very conservative: all my source files have a limited width of 80 characters.)
Confirmed.

Rene

[Andrew C.]

Hello,
Extension 1: since lines is a valid table attribute in the ATTRIBUTES section it should be valid for an explicit table container.

Is it? That's sneaked past me! I don't use <t > tables...

Extension 2: yes, simplifies reading a form file. Especially when forcing source files to have a limited number of columns. (I'm very conservative: all my source files have a limited width of 80 characters.)

Yes, very wide tables are quite a problem, but I've found that using the scroll attribute and aggressively truncating any CHAR column over about length 15 works very well, and 98% of all real data STILL displays fully. Chopping char fields literally in half is nearly always satisfying. Multi-line tables would be really nice to have, but probably not easy to achieve!

Something similar; I tried a trick on a hunch and discovered it's quite easy to get multi-line table headers. The hunch works probably due to a Qt feature; I don't know if the Silverlight client, GWC or GJC also support the feature. What I did was inject a newline character into the text attribute of a column and it rendered the header (and all headers) on two lines. Since | is a very unusual character to have in a table column header (and a quick grep confirmed we did not have any) I made my forminit callback function do this:

Code

    let nl = dn.selectByPath('//Table')
    for i = 1 to nl.getLength()
        let tb = nl.item(i)
 
        for j = 1 to tb.getChildCount()
            let dnCol = tb.getChildByIndex(j)
            let str = dnCol.getAttribute("text")
            let l = str.getLength()
            let k = str.getIndexOf("|", 1)
 
            if 1 < k and k < l
            then
                let str = str.subString(1, k - 1) || "\n" || str.subString(k + 1, l)
                call dnCol.setAttribute("text", str)
            end if
        end for
    end for
 

So our programmers only have to put | into the column headers and they can have more words in it. Looks nice too.

What's your feeling about this working in the Silverlight client? If it's not currently working in GWC I expect we could get one of our Javascript programmers to solve that.

It occurs to me now that the form compiler could look for two lines of table headers and do this formally. What's the possibility of that being achievable? I wouldn't like to go more than two lines, because screen space is already hard to find!

[Rene S.]

You can have multi line table headers without patching the form at runtime.
Simply use the TEXT attribute in the ATTRIBUTES section of the per-file.

EDIT f1 = FORMONLY.f1, TITLE = "First\nSecond";

 

[Andrew C.]

You can have multi line table headers without patching the form at runtime.
Simply use the TEXT attribute in the ATTRIBUTES section of the per-file.

great - that's easy enough. And because you're saying this, it implies it's a supported behaviour across all clients?

Supporting it literally in the form as I suggested would be nice to have, but certainly not a priority with everything else available.

Cheers

[.]

just putting them out there...

we've derived great value from extending the syntax of tables with:

Extension 1

Code

table (lines=10)
{
   Col1    Col2    .....
  [A1    ][A2     ] ....
}
end

The pre-processor replicates the last line N times from the lines= attribute. This saves effort when editing and viewing a table.

Andrew,
Why not using HEIGHT attribute ?
See https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/FormSpecFiles.html#FF_CONTAINER_TABLE

Code

table (HEIGHT = 10 LINES) 
{
   Col1    Col2    .....
  [A1    ][A2     ] ....
}
end

Ok, the current implementation is front-end side only and the runtime is only notified about the real height once the front-end made the update, but with multiple dialogs it should not be an issue.

[Andrew C.]

Why not using HEIGHT attribute ?
See https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/FormSpecFiles.html#FF_CONTAINER_TABLE

Our thing predates that stuff, but it makes sense to adapt - that way the final .per files will also look cleaner rather than having 10 copies of the same line in the old style. I guess the only innovation remaining is the "stacked" attribute. Often I sit here converting forms to use stacked and I tell myself I should pass the idea on - 3 years later, here we are!

One point I should mention with stacked; if the programmer draws

    Payroll Code [PC  ]

where the label is much wider than the column, the label would be truncated initially, so the pre-processor adds a WIDTH=n attribute to the field to ensure the label is fully shown. Of course if the size of the label and field are radically different this could make the width of the table too wide, so it falls to the programmer to be sensible when labelling. Also I've just realised I need to take the use of label newlines into account when calculating the width...