Hi Andy,

>Another programmer introduced me to using DO CASEs like your sample below.
>To me, this code is much more readable than nested IF statements.
>Jim does not like this style.

>One thing to point out is that in the sample below, RecordHasChanges()
>and SaveChanges() are not some arbitrary methods.
>If RecordHasChanges() returns .F., your code evaluates the next CASE.
>So I see the entire DO CASE as relating to saving a record, and if saved, ordering the item.

Well this is intended. This case statements just insures there are no unsaved changes: It save changes if there are.

Walter,


>

>>> DO CASE
>    CASE THISFORM.RecordHasChanges() AND !THISFORM.SaveChanges()
>        && Failed to save the changes
>
>    CASE !SEEK(cItem,"Items")
>        && Item does not exist
>
>    CASE Items.Discontinued
>        && Item has been dicontinued and thus cannot be ordered
>
>    CASE nOrderCount = 0
>
>    CASE nOrderCount > 0 AND !oBizOrders.Order(cItem, nOrderCount)
>        && Could not order
>
>    CASE nOrderCount < 0 AND !oBizOrders.Order(cItem, nOrderCount)
>        && Could not return order
>
>    OTHERWISE
>        && Order has succeeded
>ENDCASE
><<
>