Four Js Development Tools Forum

Hi all.

Currently attempting to create my first reports. My first question (of many I suspect) is how can I stripe my ON EVERY ROW output, where odd rows are shown in a different background colour to even rows?  I thought I might be able to use an expression for the background colour, but there does not appear to be a way to detect the odd/even row number or the current row number for the condition, at least as far as I can see... So how to I achieve this?

TIA,

David

Hi David,
You could ship an integer variable that gets incremented and which is shipped with the other data like this:
ON EVERY ROW
    LET rowId=rowId+1
   PRINT rec.*,rowId
Then in the design you could have the following RTL expression on the background color property of the row stripe as follows:
bgColor="{rowId%2==0?Color.LIGHT_GRAY:null}"
This expression makes use of the ternary conditional operator to make all odd rows have a light gray background. The even rows will have a transparent background.

Best regards,
Alex
 

Small correction: The coloring is inverted so that even rows are gray and odd rows transparent.

Thanks, that works just fine. I was on the right lines, but got a bit fixated about looking for a current row value, when I could have just generated a row number myself for this purpose!

My next issue, which is more of a niggle, but often data fields names are longer than their display area. Normally when this happens the data field name is clipped and shown with ... on the end but on the odd occasion the field does not do this and is shown across multiple lines (see attached), which then messes up the rest of the layout in design mode.  What is causing this?

TIA,

David

It might be that you are using a WORDWRAPBOX (the designer chooses this over WORDBOXEs when the field length (e.g. CHAR(80)) exceeds a certain length).
From the top of my head there are two solutions to the problem of wrapping display in the designer that I see:
1) Use the "Toggle View" toolbar button to toggle between seeing the expression and seeing their computed values based on sample data.
2) Use the "Convert To" option in the context menu to change from using a WORDWRAPBOX type to a WORDBOX type which then doesn't wrap (also at runtime).

An afterthought: In your screen shot I noticed that the fields only partially have gray background. Is it possible that you have set a fixed height for these fields. That is not a good idea since WORDWRAPBOXes will want to expand vertically if the text doesn't fit in the box. If the text should not wrap then you should indeed use a WORBOX instead.

Thanks they were indeed WORDWRAPBOXES so I converted them back to WORDBOXES and it looks normal again now :-)

I had been messing about with a fixed height. On occasions I inadvertently mess up the heights when moving fields and this is turn messes up the central alignment so I'd set them manually back to a fixed height

Thanks for getting back. It is uncommon to set the height on any of the text elements (WORDBOX, WORDWRAPBOX, DECIMALFORMATBOX, DATEFORMATBOX, ..). You can of course do it but you will likely struggle with baseline alignment if you need to align with other items (there is no option to vertically align the text within it's box). Also, if you leave it up to the system to compute the height, the report will react better if you change the font.

Regards,
Alex

David,

Our preference is that you start each new question in a seperate thread.   For example I am going to reply to your earlier question on striping and as you can see the conversation will get muddled.


Alex's suggestion is included in the documentation http://4js.com/online_documentation/fjs-gst-manual-html/#gst-topics/t_grd_tbl_col_alt_cells.html

You should note a few things with this solution.

1. If you are physically printing the pages, you might want to consider how much ink you are going to use.  With gold bar / green bar / zebra paper that was on pre-printed paper and if you look carefully that was not a solid background, see this image from the Wiki page on the topic https://upload.wikimedia.org/wikipedia/commons/thumb/f/fe/Green-zebra-paper.png/220px-Green-zebra-paper.png. 

2. Having the odd number rows transparent has slightly less ink consumption that even number rows transparent.

3. By including a row number in the data, you need to consider what happens if a row does not get printed.  A report designer could add some logic so that the Visibility Condition of a row is FALSE e.g. line_value > 0.  IN that case with this solution, you will get two odd rows or two even rows adjacent to each other.

To aid visibility of rows and use less ink, you might consider a solution involving top and bottom border property of each row.

Reuben







 

Thanks Reuben. For readability I was only going to ask one question at a time but I'll keep them in separate threads from now on. Yes I did think about ink usage but the reports are only rarely printed and have always looked that way. I'll run a bordered version by the end users to see what kind of reaction I get...