>Hi Cetin
>
>>For complex situations I prefer methods. For long expressions you can simply use text..endtext or string concatenation.
>
>okay thanks. I understand the idea to create a string to be assigned to a variable using TEXT ENDTEXT for hair-pulling-free editing if nested IIF()s
>
>>Your case however is neither complex nor long. You misguided everybody with title I guess.
>
>Not my intention to be misleading had I not been lead myself. I had a few more conditions in this expression which I pruned before pasting here. The reason for pruning was that I was trying to add more condition to this and wanted to see it in a messagebox and the dynamic string came up truncated, now I know messagebox displays longer text then 256 and this was showing me only 256 characters, so I removed a few extra-prudent checks I had in there and brought it down to about 190 characters. Now I needed to add more characters which would bump the 256 limit. But further test leads me to believe that 256 limit is not the case, but then is it?
>
>>Solution was much simplier:
>>
>>

TEXT TO .DYNAMICBACKCOLOR TEXTMERGE NOSHOW PRETEXT 15
>>(IIF(THIS.ENABLED AND !THIS.READONLY,
>>   <<goApp.nBackColorFld>>,
>>   <<IIF(goApp.nOSVersion < 5.01, goApp.nBackColorForm,  THIS.BACKCOLOR)>> ))
>>ENDTEXT

>
>Thanks I will implement the TEXT-ENDTEXT

There isn't a limit of 256 (only there is 255 characters limit for string "literal". A literal is anything between quotes:

StringVariable = "Literal up to 255" + "another literal up to 255"

String variables, by documentation, can be up to 16 Mb.

What I meant, you made it complex, in your expression:
1) There was an unnecessary empty(recno()) check - In a grid that would never be .T.
2) What you need was to assign constant values for colors but unnecessarily adding expression. If you meant to respond to application wide changes promptly even when this grid was active, then might be.
Cetin