Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1] 2 3 ... 10
 on: Today at 11:12:14 am 
Started by Alessandro (Efisio) R. - Last post by Alessandro (Efisio) R.
Hi everyone,

I have encountered a little and annoying graphical issue with GBC default display method for messages and errors (MESSAGE and ERROR BDL instructions).
Since they don't appear in a fixed and specific position but they pop over the underlying window, they could cover a little part of the form content.
This obviously has never happened in the GDC since messages and errors have their form space in the bottom of the window.

GBC has reintroduced the display of menu instruction title in a manner similar to the GDC display of the messages and errors, so I am wondering if the display of errors and messages in the GBC could be achieved like this.
This can probably be implemented through editing GBC templates and javascript code.
Can anyone help me?

I put as attachment a few screenshots, the 4st styles file and the per and bdl code to replicate the "issue".


 on: January 22, 2021, 03:35:01 pm 
Started by Gary C. - Last post by Sebastien F.
After internal discussing, we can suggest you this solution:


 on: January 22, 2021, 11:05:53 am 
Started by David H. - Last post by David H.
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...

 on: January 21, 2021, 10:36:03 pm 
Started by David H. - Last post by Reuben B.

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.

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?


Hi David,
You could ship an integer variable that gets incremented and which is shipped with the other data like this:
    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:
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,

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

Alex's suggestion is included in the documentation

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

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.



 on: January 21, 2021, 05:43:24 pm 
Started by David H. - Last post by Alex G.
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.


 on: January 21, 2021, 05:11:27 pm 
Started by David H. - Last post by David H.
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

 on: January 21, 2021, 04:23:38 pm 
Started by David H. - Last post by Alex G.
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.

 on: January 21, 2021, 04:17:37 pm 
Started by David H. - Last post by Alex G.
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).

 on: January 21, 2021, 04:08:24 pm 
Started by Olivier E. - Last post by Olivier E.

 Fours Js support request server under maintenance

Dear Customers,

The Fours Js support request server is planned to be under maintenance on Tuesday, January 26th, 2021 from 09:00 am till around 12:00 pm (GMT+1).

During this maintenance period to raise a support request with:

  • the European support team (For UK customers, please see below),  please send email to or call +33 3 88 18 61 24.

  • the Australian support team, please send email to or call +612-8004-5890.

We apologize for any inconvenience caused.

Best regards,

Four Js Support team

 on: January 21, 2021, 04:05:29 pm 
Started by David H. - Last post by David H.
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?



Pages: [1] 2 3 ... 10
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines