Edhy,



When you BeforeDelete event handler is called, the user has already confirmed or canceled the delete, so the line



is not going to do much at this point.



What you need to do is to set this in the designer for the form, the in your BeforeDelete, handle the confirmation for the user. So, the logic in you BeforeDelete would be:



- Check that all child objects are deleted (current logic, minus call to turn off AutoShowDeleteConfirmation)

- If any children found, show message (as your doing), cancel delete (as your doing), exit for, then exit handler

- If no children found, get confirmation from user that they want to do delete.

- If they cancel, cancel delete (e.cancel=true).



Hope that makes sense.

Hi Greg,

I tried your suggestion, but the problem is that when entering into the form's BeforeDelete() event, the delete confirmation message is already shown, wich leads me to believe that this message is only displayed in the BO.

I ended up creating a form's public var:

Then in the BO's BeforeDelete:

Then in the Form's BeforeDelete:

This way, the AutoShowDeleteConfirmation will work if the end user wants to delete a record with no children and will get the confirmation first.

Edhy Rijo

The approach I took to solving this issue was to subclass BusinessLayer. In my custom business layer I shamelessly lifted someone else's business rules code to create my own ConstraintRules. Whenever a delete is called on my business objects a CheckConstraintsOnCurrentRow event is raised that is handeled by CheckConstraintRules in my BO. Within the BO I have private methods that are used to check for possible constraint violations. If one is found I have a AddConstraintViolation method (which is very similar to AddBorkenRule ) that adds violations to the ConstraintViolation collection. The custom business layer fires a ConstraintViolation event if violations exist that contains the collection of violations which in turn contains the error (violation) message/s added by AddConstraintViolation method. I can either handle the ConstraintViolation event or the ConstraintViolation collection and present the user with a friendy message before SQL barfs out a not so friendly one.

While I try to use cascading deletes where ever possible there are a number of situations where that doesn't work. Adapting the business rules approach has worked out well for me.

-Larry

Hi Larry,

Thanks for that information, I knew there should be a way to handle this with more control on the developer.  Unfortunately, I am pretty new to .NET and VB and at this time I am not sure I would be able to do a class like that wihout any sample code. 

So far for this small project I think I can handle this situation with my previous posted code, but I really would like to see SF taking your approach and enhance the framework to deal with this situation directly.

Edhy Rijo

Well, I'm not sure that the framework could handle this situation correctly. As has been mentioned, there are a bunch of ways to handle this (ensuring that children records are deleted before deleting a parent record), including setting up the tables so you never have to do this sort of check. There is no way for the framework to know what particular approach you'd take, so any arbitrary solution would be limiting. So, instead the framework does allow for special cases. In this case there are at least three choices:



- sub class BusinessLayer, override OnBeforeDelete, which offers the best control

- handle the BeforeDelete event of the form

- Handle the BeforeDelete event of the BO

- ...more I'm sure



The trick is to understand how things work enough to get the right solution for your needs. Unfortunately, that just takes time and what you are doing right now...asking lots of questions (I should know, I've asked about a million ). When I was starting out, I often felt the same...the SF framework should do _____ (fill in the blank). Often it was more I just didn't understand how easy all this subclassing makes things (plus all the other .NET goodness). I'm refactoring some code I wrote about 6 months ago...boy did I do things the hard way then. I'm sure in another six months, it will be the same again (although by then, I'll likely be in VS2008, with linq, so god help me! ). Of course, many of your suggestions are excellent and given some more time, I'm sure we'll see the BO Mapper doing lots more work for us, etc.



So, don't get discouraged, it'll get better sooner than you think..you're working hard and asking the questions!



Good luck!

Greg

Hi Greg,

Once again, thanks for the inside, you are in the right spot about what I am going thru, after 20+ years working with VFP one day a very good friend of mine (also a VFP developer) pushed me to start learning .NET and we start buying books and kind of compete each other, but at some point, the only way to really push yourself to learn a whole new language and environment is to start with a serious small project, and I took this project which I could have finished it already in VFP, to learn .NET and after looking for a framework I decided to go with SF. 

I have been working with a VFP framework for over 10 years (the same framework) and you bet there are a lot of stuff I miss so in order for me to keep focus on the project, learning the new tools, and trying not to ask too much dummy questions, I simply post my comments/request for things I believe can be improved in SF in the future (of course I hope is the near future :hehe and thanks to you and the others I am getting there one step at a time.

Edhy Rijo