Lincoln,

For handling cascading deletes, your best bet is to allow VFP's referential integrity functions to take care of the process. VFP's RI has some known problems, but I do not believe handling cascading deletes is one of them.

Right now I am working on a project that contains a form that seems similar to the situation you describe. It has five main pages attached to cascading tables in a .dbc. The parent table is the source for the controls on page 1, the child table for page 2, the grandchild table for page 3 and so on. I have not had any problem with cascading deletes using RI.

If you SET DELETE ON none of the deleted records should appear in your form -- but just to make certain, I always code so that if there is no record in the table for a form -- because it has not yet been created or all of the records have been deleted -- I set the table at EOF() using GO BOTTOM and SKIP. when the table is EOF(), the controls associated with the table are grayed out and appear disabled, in fact they are "disabled" in the sense that they will accept no input even though the .enabled property still shows .T.

I control packing of deleted records by putting an array, aPackList[] in my base form. When a record in a table is deleted, I write the nane of the table to aPackList[]. When I exit from the form, a method called from .unload attempts to open the tables exclusively and pack them. If someone else is using the tables, the pack will fail, but it does not have to succeed every time since there is not particular harm in allowing deleted records to remain in a table for a short while.

As far as the Edit/No Edit dichotomy, this was probably a good way of controlling edit access by the user back in the dBaseII days, but it does not seem applicable to the Windows environment. A better way to control access is to use the .enabled and .readonly properties of the individual controls. A control that should _never_ receive user input should be set to .readonly.

A control that may conditionally receive user input should be set to .enabled=.T. when the condition is met, that is, its availability to the user for input should be a dynamic process. An elegant way of controlling this is to place a .SetEnabled() method in each of your abstract control classes. When a control object is derived from the abstract class and placed on your form, the code your write in SetEnabled() determines when the control should be enabled for user input.

A simple example is the situation where controlB may receive user input only if a valid entry is made in controlA. Put something like the following in controlB...

*-- controlB.SetEnabled()

LOCAL llEnabled  && initialized to .f. by VFP
WITH this
    IF .NOT. EMPTY(.parent.controlA.value)
        llEnabled = .t.
    ENDIF
    .enabled = llEnabled
ENDWITH

RETURN

My data controls are set up to automatically invoke .Setenabled() when the control is refreshed -- that way when you move to a new record, all of the controls on the page are enabled/disabled based on the data in the new record.

regards,