Ben, considering your full explanation (which is important for some up front decision making) and the sample Peter offered, provides an important value to this event. Even if some explanation was provided in InitializationPrioprity, I think second time explanation drives the point home!



Thanks for reply!

..ßen

It should already be in the help file somewhere under InitializationPriority.  Maybe we just need to link to that from the ParentFormLoading event documentation...

Thanks Ben; Great reply!

Makes sense!

Good point!



Ben, I think this reply should make it to help file!

Thanks!

..ßen

Yes, Peter is correct.  The ParentFormLoading event is part of the IInitOnFormLoad interface implemented on the BusinessLayer class (it's also implemented on all of the list controls).  The ParentFormLoading is not meant to be handled within the BO class itself (unless you have come code that always needs to be executed when the form loads, in which case, yes, you should use it ), it's meant for the form to handle the method to allow you to place your population code in it. 

It's really 6 one way and 1/2 dozen the other... the ParentFormLoading on each BO is raised within the OnLoad of the form, right before the form's event is raised, so they are both equivalent.  The only difference is that the Form's Load is a "catch-all" and is a good place to put a PopulateAllBOs() method that can be called in a refresh.  The ParentFormLoading of the business object, since it's part of the IInitOnFormLoad interface gets raised according to the BO's InitializationPriority.  So, if you've got 3 BOs and 2 lists, and you need to call BO1.Fill(), List1.Requery(), BO2.Fill(), List2.Requery, BO3.Fill(), in that order, then you'll want to use the ParentFormLoading event and set the InitializationPriority on each of the objects in to control the order in which the event fires for each of the 5 objects.

Peter; That was a very valuable reply and it pointed out an important point that I had missed (I'm still new at this SF ;-)). The fact of encapsulating a set of code to a BO which doesn't matter which form calls it, will be run and gets parameters from the form at loading time.



Thank you for the reply!!!

..ßen

Hi Ben,

I can tell you what we have decided to do and it seems to work ok so far. We do a call to a 'populate' sub from within FormLoad. This has the advantages:

1) We can easily set any default data selection criteria, e.g. just show transactions for last 3 days, before 'populate' is called.

2) These data selection criteria defaults can be, of course, be form specific rather than an arbitrary values selected for the BO itself which makes the BO easier to reuse.

3) If we have a 'refresh' button on the form (normally we do) then clicking 'refresh' simply calls the 'populate' sub. This would be done of course if the user changes the data selection criteria, e.g. all transactions for last month.

This being said we also use ParentFormLoading for all our lookup BO's that will be needed on a form, i.e. those that populate selection list like combo boxes. Then all we need to do with lookup BOs is drop them onto a form and use as needed. Actually we use a little trick on that side of things. We put the stored procedure name that is used to populate the BO into the UpdateStoredProcedureName property then, all our lookup BO's have identical ParentFormLoading code:

    Private Sub boluSPC_ParentFormLoading() Handles Me.ParentFormLoading
        If Me.UpdateStoredProcedureName.Length > 1 Then
            Me.FillByStoredProcedure(Me.UpdateStoredProcedureName.ToString)
        End If
    End Sub

We actually use this approach in our main BOs as well. It means we can use more boilerplate code.

Cheers, Peter

BO has an event called "ParentFormLoading" which allows me to connect to my customfill method. I can also call my customfill in the "FormLoad" of my form.



Naturally, I'd use the "FormLoad" event, but when I see BO has that event, I began to doubt whether the "FormLoad" is the way to do it. So, which way is the recommended way?



Thanks!

..ßen