>Here's a quote from a recent thread:
>

loColumn.DynamicFontBold = "'IIF(THIS.PARENT.gnRecNo = RECNO THIS.PARENT.RecordSource), .T., .F.)'"

>I wouldn't be starting on this if this was the only one, but I'm seeing the IIf({expL}, .T., .F.) just far too often, so I started wondering what made this become customary.
>I've even seen IIF(.T., .F., .F.) in a property (where a string containing a logical expression was expected).
>What I don't understand is why would anyone want to write
>

If DESCENDING()
>	Thisform.lSaveAscending = .F.
>Else
>	Thisform.lSaveAscending = .T.
>Endif

>instead of
>

Thisform.lSaveAscending =NOT DESCENDING()

>Or why is this form
>

llHasValue=iif(empty(lcValueString), .F., .T.)

>preferrable over the
>

llHasValue=not empty(lcValueString)

>Was it a readability issue, or what? I'm still thinking that
>

c=a#b

is more clear and more readable than
>

c=iif(a=b, .f., .t.)

or, worse,
>

if a=b
>   c=.f.
>else
>   c=.t.
>endif

>Is it just my pet peeve, or are there some recommendations about this?

Agreed 100%. Our classes still use the last example. Once ~ year ago I put some efforts into improving their functionality and speed, but it was not implemented, so I give up.

Quite recently I made a simple suggestion about enhancement in InGrid functionality. I was suggested to add a new Property, say, cPartKey, then in KeySeek method check, if it's not empty,

if !empty(this.cPartKey)
   this.cSearchString=evaluate(this.cPartKey)+this.cSearchString
endif

In other words, this simple enhancement allows me to type something in Streets column, but use upper(ccode+town+street+...) index. But it was not implemented.
Lots of my suggestions were in vain. I'm starting to fill desperate now...