The genesis of this blog is when a client requested that a certain field in a certain report would be coloured. We were talking about the status of a purchase order line, and I had previously added to the table of possible line statuses a field that defines in which colour will appear the status. I explained to the client that there was no problem in defining the background colour for the given field, but defining the font colour was problematic as the field is linked to a table. The client was not prepared to compromise and requested that the font colour be set according to the value of the colour in the table.
In other words, I should remove the link from the field. My first solution was to move the field from its position in the report generator as a regular field to being an expression (i.e. moving the field definition to the first son form of the line). This worked, but I don't like it when reports have standard fields as expressions: the field title gets lost and one can't see what the field definition is without looking closely. Then another solution occurred to me, exactly at the same time as the client suggested something that he must have come upon by accident.
My solution was to set the 'target form' value to NULL; this field is in the same son form as where expressions are defined. I mentioned it in a previous blog albeit in a different context. And indeed, defining the target form of the line status field as NULL removes the link and allows the font colour to be changed.
The client said that entering NULL in the field 'form defining a choose list' in the HTML definitions son form for a report field would also work. I was not previously aware of this field. Anyway, I entered NULL in this field ... and saw that in the field that I do know, the target form for the field, NULL also appeared!
I've just spent about ten minutes going over several reports and making the target form NULL for fields such as order type, part unit and order status. One generally has no reason for clicking on these values.
