Well, I'm back to SF after a few years and some other adventures (an Ironspeed web app, some data mining experience...) and am converting a VFP (VPME) application.  (Hello to some old VPME'ers out there like Edhy).  I'm really liking the core SF functionality but have some questions around the fringes.

So my first question concerns displaying empty dates.  I see that the DateBox is now the preferred way of editing dates and it has an EmptyValue property for trapping a place holder value (like '1/1/1800') and displaying it as blank. 

What is the best way to trap and hide these place holder dates in other places, such as in ListView columns?  I see I have two options to format a column:  Format String and PopulatedThroughEvent.  I suspect the preferred way is to use PopulatedThroughEvent to trap the place holder date value and return a "" string.  Is that about right?  Any examples?

Thanks in advance,

Larry

Hi Larry,

Glad it is working for you now.


I use Firefox browser and when replying simply click the "IF Code" and select "Code Snipped", then I copy and paste my code between the codesnippet tags and to keep it formatted properly, I have to add a carrier return at the end of each copied line, otherwise it would be pasted as a one line only.

See Sample Image:

         '-- Bypass this method when the form is being loaded.
         If Me.FormIsLoading Then
             '-- Clear the BO so no previous record are re-used
             '   This line is causing a problem with previously modified records.
             '   for now do not clear the BO.  8/12/2009
             Me.BizTransactionItemsStock1.Clear()

             ' ER 10/27/2010: Added the Requery to force the Edit Button cmdChangeActiveQtyAndStartValues
             ' to be enabled/disable properly.
             Me.lstItemsStock.Requery()
             Exit Sub
         End If

Edhy Rijo

Thanks Edhy,

Using Firefox helped me see the formatting codes in the text editor.  They were hidden in IE...

So here is my code (for various reasons I'm using 1/1/2200 to indicate an "open" ending date)...

Private Sub CoverageListView_RowPopulating(e As MicroFour.StrataFrame.UI.Windows.Forms.RowPopulatingEventArgs)
 Handles CoverageListView.RowPopulating
        Dim bo As CoverageBO
        bo = 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 Sub

And here is the result showing blank "End Pop" column in the listview on a test screen...




Larry

Hi Larry,

I am glad you figured out, it looks good.  One thing I would change in your code is instead of using Dim bo As CoverageBO I would use the "Using...End Using" as posted in one of my sample code in previous posting in this thread just to avoid any possible memory leak by no disposing the bo object and keep in mind that this code will run for each created row in the listview, so with many records loaded, it could just bloat up at any point.

Edhy Rijo

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