Hi,

The scenario :
A grid on a form has several columns with DynamicBackColor set.

The symptoms, in lan mode :

1. bizarre behavior with the colouring; initially the colour on each row in a column is correct (some are coloured, some are not, etc) but when you enter & leave any cell in the column then the colours go crazy - all cells in that column are then displayed with the colour of the cell just left, e.g. if you leave a red cell then all cells in that column go red
2. if you open an InputBox while that form is active then you get an error : "Expression is invalid. Use a valid expression for DynamicBackColor". Only an InputBox, another form or a messagebox is fine.

This has worked fine for many years before FiC.
I have not tested this in web mode.
Even stranger, in my scenario there are 8 columns with DynamicBackColor set and only 4 of them are having this problem; there is nothing much different between the expressions that work and those that do not.

My partial solution :
I have temporarily removed aw.awTxt.BackColor_Assign
I have tried changing the code in all sorts of ways (no code at all, nodefault, other things) but the only fix is to actually remove the entire event.
The only code in there deals with a VFP bug assigning a color value that is too large - I have never encountered this problem before (until I started debugging this event and saw it happening - I wonder if enabling the event actually causes the VFP bug?).

How does this relate to DynamicBackColor on a grid column?
I have no idea (VFP must internally set textbox.BackColor I suppose), but the fix works (partially, it fixes the colour weirdness but the InputBox error remains).

So, some questions :
Has anyone seen something like this before?
Is BackColor_Assign really necessary? I am hoping it is not, otherwise I will need to maintain a different branch of textbox inheritance that does not have awtxt as its parent.

Very strange...

Thanks
Paul

Hi Paul,

there are 8 columns with .DynamicBackColor set and only 4 of them are having this problem

any noticeable difference between the .DynamicBackColor expressions of these columns? could you post them just in case?

awTxt.BackColor_Assign code

procedure awTxt.BackColor_Assign
LPARAMETERS tBackColor

IF Vartype(m.tBackColor) == 'N';
 AND Between(m.tBackColor, 0, Rgb(255,255,255)) && sometimes, VFP assigns Rgb(255,255,255) * 4!
  this.BackColor = tBackColor
ENDIF

I have noticed a missing m. in this code (this.BackColor = tBackColor instead of this.BackColor = m.tBackColor). Any chance .recordSource has a field named tBackColor?

This code is more than 6 years old and we can't remember the case and reason for adding it…

I think we can remove the awTxt.BackColor_Assign method and warn users that they'll have to add it manually to some of their textbox classes if they get this error:

Here is a DynamicBackColor expression that works :

"iif(nvl(SalesOrderBomheader.ItemGrossWeight, 0) = 0 and !nvl(SalesOrderBomheader.NonStockItem, .F.), DefaultsObject.Colours.System.Warning1.BackColour, this.BackColourReadOnly)"

Here is one that does not :

"iif(nvl(SalesOrderBomheader.ListPrice, 0) = 0, DefaultsObject.Colours.System.Warning1.BackColour, this.BackColourReadOnly)"

.
I have now eliminated the InputBox problem by changing the expressions causing a problem - I have simply replaced this.BackColourReadOnly (a custom grid property holding a colour number) with 16244959.
Note that the expression that works still uses this.BackColourReadOnly quite happily, I only had to change to a hard-coded colour for the expressions that do not work!
I cannot explain the weirdness...

tbackcolor - lol, no I do not have a column named this!

Thanks for removing the BackColor_Assign, that will reduce the weirdness for me!!

Paul

this refers to the grid while .dynamic* are defined , and probably executed, at the column level… I wouldn’t dare refer to the grid in such context …

You could set these .dynamic* expressions in grid.Init() by substituting the properties by their value — advisable as these expressions are evaluated very often:

procedure grid.Init()
…
this.columns(x).dynamicBackColor = textmerge("iif(nvl(SalesOrderBomheader.ItemGrossWeight, 0) = 0 and !nvl(SalesOrderBomheader.NonStockItem, .F.), <<DefaultsObject.Colours.System.Warning1.BackColour>>, <<this.BackColourReadOnly>>)")

this definitely refers to the grid during Dynamic* evaluation; as I say, this code has run fine for many years.
I can (and do) change our production code to work around issues introduced by FiC, but I'm always looking for the approach with the lowest impact on the existing code-base.
What is still strange after all this is the same object properties are fine in some DynamicBackColor expressions and not in others.
I just need to move on... 😉

Thanks
Paul