The NO-UNDO behaves the same for a CLASS reference as it does for any other type of variable. If it is UNDO, any reference modification is undone and any NEW'd class is deleted on the roll back of a transaction. For example:
DEFINE VAR cls AS foo NO-UNDO.
DO TRANSACTION:
cls = NEW foo().
/* This shows for example: foo_1120 foo_1120 */
MESSAGE cls SESSION:FIRST-OBJECT
VIEW-AS ALERT-BOX INFO BUTTONS OK.
CREATE customer.
customer.NAME = "laura".
UNDO, LEAVE.
END.
/* If foo is NO-UNDO, the following statement shows: foo_1120 foo_1120. But if foo is UNDO, it shows: ? ? */
MESSAGE cls SESSION:FIRST-OBJECT
VIEW-AS ALERT-BOX INFO BUTTONS OK.
This resetting of CLASS values happens only when transactions are rolled back or undone, as is true for any other type of variable. So, this example works differently because no transaction is involved:
DEFINE VAR cls AS foo NO-UNDO.
DO ON ERROR UNDO, LEAVE:
cls = NEW foo().
MESSAGE cls
SESSION:FIRST-OBJECT
VIEW-AS ALERT-BOX INFO BUTTONS OK.
UNDO, LEAVE.
END.
/* You will see : foo_1120 foo_1120 regardless of whether the variable is undo or not. */
MESSAGE cls SKIP
SESSION:FIRST-OBJECT
VIEW-AS ALERT-BOX INFO BUTTONS OK.
Similarly, when the value of a class property is changed during a transaction and the transaction is undone, the AVM restores the value of the property to its prior value.
If you do not need the value of the property to be undone even when it has been changed during a transaction, use the NO-UNDO option.
Please note that the NO-UNDO properties are more efficient and should be used whenever possible.
