Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Hi Larry, Larry Tucker (3/11/2012) So I assume I'll start repeating myself in all my BOs and finally say, "Duh"... put this in my own base class.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. Larry Tucker (3/11/2012) 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.Yeap, go for it and can assure you once you get the confidence you would start adding more and more functionality.
Edhy Rijo
|
|
|
Larry Tucker
|
|
Group: StrataFrame Users
Posts: 69,
Visits: 308
|
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
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Larry Tucker (3/9/2012) ...How much do you have the SF classes subclassed?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
|
|
|
Terry Bottorff
|
|
Group: Forum Members
Posts: 448,
Visits: 12K
|
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.
|
|
|
Larry Tucker
|
|
Group: StrataFrame Users
Posts: 69,
Visits: 308
|
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
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
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
|
|
|
Larry Tucker
|
|
Group: StrataFrame Users
Posts: 69,
Visits: 308
|
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
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
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
|
|
|
Larry Tucker
|
|
Group: StrataFrame Users
Posts: 69,
Visits: 308
|
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
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Hi Larry, Glad it is working for you now. Larry Tucker (3/6/2012) BTW, how are you formatting the code and uploading the screen shots in your replies? They are very clear. Is there a Forum guide somewhere that explains this?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
|
|
|