>>I agree with Bret and George. Also, to make one small addition to the readibility issue, CASE structures are alot easier to read and debug than nested IIF() statements. I spent half a day one time changing IIF() statements, some nested 5 to 6 levels, to CASE structures in a program I inherited. The readibility of the code is a million times better and there was no visible difference in performance.
>
>Agree 100%. If there's any chance your code will ever become legacy code for someone else, then it's better to go this way. I've been on the other side of that coin, and inheriting messy & difficult IIFs isn't much fun...

Agree too. It will highly depend on expansion or not.
If only do simple Assignment on Variable,
I even want to try any .NOT. case.

Such as a Button action as On/Off Switch!!
* btnSwitchForm.Click
ThisFormset.fOTherForm.visible = !ThisFormset.fOTherForm.visible

because Not gate calculation is 3-5 times faster than comparasion nor
.AND. .OR. gate in thm. Instead of:
ThisFormset.fOTherForm.visible = iif(ThisFormset.fOTherForm.visible, .f., .t.)

But in some case, In order to further expand, I even use DO..CASE instead of IF..ELSE..ENDIF
For All the KeyPress Event procedure.
Even only I take one nKeyCode, I use Do Case as very easy on expand as
need to further concern the other additional functions!

* Form.KeyPress
DO CASE
CASE nKeyCode = -1 && F2
ThisForm.cmdGroup.CmdAddNew.Click

CASE nKeyCode = -7 && F8
ThisForm.cmdGroup.CmdDelete.Click
ENDCASE

In case I need a update, search, or other additional, maintain will be easy!

The weak wait for chance, The strong bid for chance,
The clever notch up chance, but The merciful give you chance.