I did the test as follow and it worked just fine, of course passing the False to the DeleteCurrentRow() method does not requires me to Save() the record :

Like I said before I think that a new property in the ListView to flag the DeleteChildRecord() as OnlyMarkAsDeleted or not, will take care of this situation and will not require us to add more code to the form whenever the ListView is used and the Delete action needs to be permanent.

Edhy Rijo

Edhy,

Let me just point out something when we address a problem...we first try to get to the source of an issue before we add a new feature.   Just because you get an error to go away doesn't mean that the problem is fixed.  Adding a property is not big deal and I have no issue doing this at some point...so just because I don't immediately say, "I will go add this right now!" doesn't mean that it has no merit...it just means that it doesn't get to the crux of the issue.

If you look at your stack trace, something was trying to bind or pull from the CurrentRow...which could be related to the code in the ListView possibly and we may need to setup a test.  Thus I suggested the manual code change to see if something else arose.  I will see if I can reproduce the error, but until I prove the error, I will not add a property.  It is more important for me to understand why there was an error so that something else is not introduced versus just providing a fix that may prevent the error but we don't know why.

Trent,

I do understand what you are saying and respect your policies.  But so we are in the same page here let me clarify the problem a little bit:

• The ListView enhancement is in beta and I am using this control a lot.
• When testing the Delete functionality I noticed that the record was only marked as deleted, and could not find a way to change this behavior without disabling the HandleDeleteAction and adding a custom code for all ListView used in this form.
• Since the mark as deleted will required a call to the BO.Save() to permanently delete the record, then I tried to do that and got the error reported.
• Based on the test you asked me to do, by calling the BO.DeleteCurrentRow(False) will work fine, then I make the suggestion to add the property to control how the DeleteCurrentRow will behave.

I am trying to move forward with this project and have not problem to take the time to investigate any problem, in fact I spend a lot of time in the forums before posting to try to get answers to my stituations, but I do really need to be ready to show this project to the customer anytime soon.  So for now I will simply add a common DeleteRecord method for my ListViews.

Edhy Rijo

Hi Trent,

I have another situation with the ListView, I guess

I am using the HandleAddAction = True to let the ListView calling the ChildForm when adding.  I added the code below to cancel the Adding if the Save() of the parent BO is not Success, but even though I am setting the e.Cancel = True, the ChildForm is being shown.  Am I using the correct logic here?

P.S.

FYI, since the ListView enhancements are still in beta, I keep posting in this thread to keep everything related to this in one place, if you prefer I can post this kind of stuff in a separate thread.

Edhy Rijo

That cancel flag doesn't logically tie into the BOs BeforeAddNew...so the cancel will not have any affect in this case.  That Cancel only has to do with adding a new row to the BO...and FYI...saving within that event could come back and slap you at some point...this is generally never a good idea.

However, it might not be a bad idea to have a BeforeShowChildDialog event on the ListView so that you could cancel it if you like.

Point taken, then where to put the save code then?  In the ChildForm I am making a reference to the ParentBO PK field value which will be -1 if not saved and brake the code.  Any suggestion?

That sounds good.

Edhy Rijo

This is the whole point of a parent relationship.  You SHOULD be able to create a child record on a parent that doesn't yet have a PK yet.  SF will automatically persist the parent's PK to the child once the parent gets a PK.  So you should be saving these records at the same time.  It isn't fair to require the end-user to save a parent record before a child gets created.  All of this should be able to be done at the same time.

In one maintenance form that I recently finished, I have 11 child and grandchild records that could be created on a new record without ever first requiring a parent record to first be saved.  So that is the first thing I would rework versus forcing the save of the parent.

• So basically all child BO should be Saved when clicking the Save button in the Parent Form? 
• I guess that if I select Undo from the toolbar that all child data will be undoed?

Guess I am still thinking as a VFP developer

Edhy Rijo

Yes.  All Save and Undo logic should occur from a single point (not the child form ) but the most common place would be the Parent form or container.

Yup...you got it

Hi Trent,

After your post, I when to check the SF Samples and after reviewing the ChildDialogFormSample.sln I think I now have a better understanding of this concept of drilling down child forms and having control of all the savings from a single point. 

I must admit that it still scares me a bit drilling down several child forms without saving and potentially undo some data that the end user may not wanted to undo, but I guess is just a matter of understanding the design purpose of the ChildFormDialog control.

I'll keep you posted

Edhy Rijo