Edhy,

Interesting.  I noticed your "Using..." approach and did not realize there was any difference in terms of memory.  I'm trying to get the hang of VB object instantiation and syntax (as opposed to VFP) and my approach looked clearer to me.  Thanks for the suggestion. 

Just to better understand.  Would adding bo.dispose() at the end of the subroutine address the potential memory bloat / leak? 

Would the "Using..." still be faster than "Dim bo as..." because it requires less initial construction / memory allocation?

Finally, I'm curious about the CTYPE() conversion you used.  It looks like the code will work without it (below).  Is there a benefit to adding it that I am not seeing?

Again,  I appreciate the discussion and extension beyond the original question.  Hopefully others find it useful too.

Larry

    Private Sub CoverageListView_RowPopulating(e As MicroFour.StrataFrame.UI.Windows.Forms.RowPopulatingEventArgs)
Handles CoverageListView.RowPopulating
        'Dim bo As CoverageBO
        'bo = e.BusinessObject
        Using bo As CoverageBO = e.BusinessObject
            If bo.COV_END = #1/1/2200# Then
                e.Values(6).DisplayValue = String.Empty
            Else
                e.Values(6).DisplayValue = bo.COV_END.ToShortDateString
            End If
        End Using
    End Sub

Hi Larry,

Again,  I appreciate the discussion and extension beyond the original question.  Hopefully others find it useful too.

Me too

Just to better understand.  Would adding bo.dispose() at the end of the subroutine address the potential memory bloat / leak? 

Yes, but as per MS documentation, the Using...End Using does a better job and it is recommended unless it is not supported by the object to be instantiated.  Check the MS documentation for better reference.

Finally, I'm curious about the CTYPE() conversion you used.  It looks like the code will work without it (below).  Is there a benefit to adding it that I am not seeing?

In most cases, you know what the object's type is, and it may work just fine without the CTYPE(), but keep in mind that in this particular case, all SF BO are inherited form the MicroFour.StrataFrame.Business.BusinessLayer which has all sort of common properties and methods to the BO, if you have your own Base BO class where you inherit your BO from, then custom methods or property will not show up in the e.BusinessObject argument, because the e.BusinessObject is of type BusinessLayer and do not have your custom methods or properties.  So Casting to the correct expected object is a good practice, not common to us coming from a VFP environment when object types are not enforced, but very important in .Net environment.

Edhy Rijo

Edhy,

Thanks again for the elaboration.

if you have your own Base BO class where you inherit your BO from,

I certainly did this in VPME... we all probably did because the framework encouraged it (having an intermediate "base" class between that of the framework and the actual classes in a specific app:  vpm... dev... and pro... classes).  Haven't thought about it yet in SF.  How much do you have the SF classes subclassed?

Larry

This has been a great discussion. I am fighting with the ctype command also and this just helped me understand a bit more.

I want to also look into the Using.... issue which I know I have not utilized but can start now.

Thank both of you for the dialog.

Not much, just a Base class for the BO which is highly recommended since I have created generic methods that are used by all BOs in this class.  Also since I started using DevExpress a year ago I use the "MicroFour StrataFrame Inherited UI" assembly to be able to use ready made SF controls which inherit from my DevExpress classes and make it easier to use DevExpress controls.  Also I have created my own DevExpress Grid class and some report controls.

Inheritance is a very power concept as in VFP, but it is done different than VFP.  At some point the right way to do this would be to create my own assembly that inherited from SF and then use those to create my applications, but so far I have not had the need to do all that like we did in VFP/VPM.

Edhy Rijo

Edhy,

Yea, I guess I start thinking about subclasses when I realize I have written the same thing 4 or 5 times... (or is it 14 or 15?).  It's amazing how much laziness can appeal:  I'll just copy this code one more time and next time I'll subclass the whole thing.

So I assume I'll start repeating myself in all my BOs and finally say, "Duh"... put this in my own base class.  Might be good to create my own BO base class before I realize I need it.  Doesn't hurt to leave it blank until then.

Larry

Hi Larry,



That is exactly what happened to me.  I was kind of intimidated to create my own BO base class, until the guys here in the forum, Trent, Ivan, Greg, showed me how easy it was to do that, much easier than in VFP and vey stable.



Yeap, go for it and can assure you once you get the confidence you would start adding more and more functionality.

Edhy Rijo