Merry Christmas to you as well

Great, thanks Trent.  All I wanted was an approximate time frame, so that works for me.  Thanks for getting the fix in there too.  Have a good Christmas!  Don't work the whole time.

We have already decided that we will reflect the functions as well in the next update.  As for an exact date on the new release, I cannot give you one.  We had initially hoped to get one out before Christmas, but we have added a phenominal amount of enhancements including VS 2008 support, so we have been slow to release until we have gone through a thorough QA cycle.  So it will probably be January sometime that we publish the new update.

Seems like a simple enough correction within the framework; however, that may get a bit messy reflecting all of the functions and methods in the hierarchy.  I hope you can get to a resolution soon.

Take care,
Bill

Business objects have a Count property on them already which does exactly what you describe.  My fill functions actually just return Me.Count.

The reason I like having them as functions returning a count is so I can do something like this:

If BO.FillAll() > 0 Then
  'Loop through the BO and do some processing
End If

Otherwise it would be:
BO.FillAll
If BO.Count > 0 Then
  'Loop through the BO and do some processing
End If

Granted, this isn't that much of a difference code wise.  However, I've already replaced probably 100 or more of the second type of call with something like the first, and changed the corresponding sub to a function returning the count.  It just makes for easier coding on my part if I do it the first way.  I basically don't want to waste a day reversing what I did when it should just be fixed in the framework to allow function on PopulationDataSourceSettings.

I ran this through my test app, and it seems to work.  My assumption is that you want the full count regardless of any subsequent browse dialog results.  This should work...as long as the FillAll() method is run initially.  You may want to consider setting the entire TotalCount property up without the need for the FillAll() method.  In other words keep them separate (although, there is some overlapping code there).

Have you considered using a property to reflect your count?  I am a bit rusty on VB (sorry), so here is a C# snippet:

private int mCount = 0;

public int CurrentCount
{
    get
        {
            return mCount;
        }
}

public void FillAll()
{
    this.FillDataTable("SELECT * FROM MyTable");
    mCount = this.Count;
}

For the count, just grab what's in the CurrentCount property of the BO.  Would that work?

Bill

Has this been looked at or fixed yet?  Please let me know something.  I have lots of Fill methods which I changed to functions in my code which return back a count.  This is starting to cause a lot of random errors in my code since I may have previously used that method to fill a combo, and changing to a function basically has broken a lot of my populated combos...giving me run-time errors when it's most inconvenient of course.

Also, any idea when we might have a new release?

We will add it to the list to take a look at.  Thanks.

Any update on this?  It's becoming a little more of a problem.  I have several FillAll Functions in my code which are used in the code to fill and retrieve a count, but used elsewhere to populate a combo.  I can't use the same function in both places right now, since I have to use a Sub instead of a Function for filling combos.