After spending a lot of time debugging the framework's code, I *think* I found the answer, but then I also found another question.

Before continuing, let me restate that my form was based on cBizObjForm. Which is what caused the problem, but then my user doesn't like cBizObjNoListMaintForm, so I had to go higher in the class hierarchy.

Here's a very rough breakdown of the sequence that takes place when you click on the DELETE button in a cListObjEdit container:

1. The cListObjEdit swaps the form's primary bizobj with its own.

2. The FORM's DELETE method is called. Since the cListObjEdit's bizobj is now the FORM's primary bizobj, guess who gets deleted.

3. If the FORM's DELETE method finds that we are in the midst of ADDING this record we just asked to delete, the FORM's CANCEL method is called.

4. If the cursor is empty after this cancellation, then the FORM's CANCEL method calls the FORM's onCancelFirstRecord method.

5. The FORM's onCancelFirstRecord method *RELEASES* the form.


Now my QUESTION:

Why is the cListObjEdit's bizobj swapped with the FORM's bizobj in order to accomplish the deletion? I don't see why the cListObjEdit container can't handle the deletion itself. Is this an example of code re-use gone wrong? (I noticed that someone else asked this during another thread I started also about cListObjEdit, but went unanswered.)

In my case (and I'm sure others' as well), we're talking about a 1-many relationship between 1 record in the FORM's bizobj and several in the cListObjEdit's bizobj. I think it's quite wrong that when deleting the one record left in the cListObjEdit's bizobj, the FORM is assuming that this is the only record that was left in its MAIN bizobj's cursor.

For example, let's suppose that I use this form to enter Clients and contacts at my clients' offices. The client is the primary bizobj of the form and the contacts are entered through a cListObjEdit.

- I create a new client record.

- Then I add one contact.

- Then I realize I added the wrong contact, so I click the delete button in the cListObjEdit

- Now, as the cListObjEdit's bizobj is the primary bizobj on the form, the form "thinks" that we have canceled on first record and releases itself. This behavior is wrong, don't you think?

Kevin, or anyone, could you please shed some light on my questioning of the design?

THanks!!!!!

Alex