Thanks for the mini time line.

StrataFrame 2.0 is picking up more and more steam as we move forward.  We are still finishing up the core of StrataFrame 2.0 which is the most complicated and time consuming area.  It will be well worth the wait, though.  I am excited about using it as well on our other product lines (i.e. medical software).  As far as time lines, we may have a beta before Christmas, but there won't be an official release until at least the January.  It will be worth the wait though, I promise!

Never a day goes by that I don't learn something new. Wow. And Version 2 somewhere Soon?

Yes, you are correct, you can have as many instances of the same BO in your form and they all be independent of each other.  Trust me, I have been amazed the more I work with SF of how flexible and useful the concept of using a BO is, and on top of that, you add all the useful methods and properties provided by SF to handle things like Filter, Sort, CurrentView and something that many may not be aware of BO.CurrentDataTable.AcceptChanges() method, in a table where you may have done many record changes and then you copy those records to another table, by calling the BO.CurrentDataTable.AcceptChanges() method will tell the BO not to complaint of the changes and ask to save the BO, very cool.

Edhy Rijo

Some days(months) I wonder where my brain is. So the second(temp) BO is its own Entity and its data does not get mixed with the original BO unless of course you choose to do so? Is that correct?

TIA.

Hi Terry,



No temporary table anywhere, just another instance of the BO either dropped in the form or programatically instantiated for the purpose on hand, here is a pseudo code:

Suppose I have a BO or OrdenItemsBO in the form, and this is used to show the Order Items in a grid or listview, then I want to do some process in another instance of the same BO:

Using TempBo As New OrdenItemsBO
     '  Now copy the records to the TempBO
     TempBO.CopyDataFrom(Me.OrdenItemsBO1, Here the copy type required by SF)
    
     '  Now I have all the records in the temp bo and I can do whatever I want, then save it and re-fill the OrdenItemsBO1 to show the changes
     For each TempBORecord in TempBO.GetEnumerable()
          ' Here do what you want with each record
     End For

     If TempBO.IsDirty = True Then
          TempBO.Save()
          Me.OrdenItemsBO1.FillAll()
     End If
End Using

Again, above is just pseudo code from my head, not a real example.  And this would be needed in case you want to process some records from the whole list.  I also use a lot of BO.Filter conditions before copying the data to the TempBO, but be aware that when using BO.Filter or BO.Sort conditions, that these must be set to empty before adding new records, or your new records will not be included in the BO.CurrentView.

Edhy Rijo

Edhy I see you use a "Temporary BO" in some of your forms. So does that mean you have a Temp table in your database or are you able to get a Temp BO some other way?

TIA

Hi Fabian,

I am glad you were able to find the information you needed, that is exactly what the forums are for. 

I keep using that technique over and over all the time, specially now that I am using the DevExpress Grid control via the SF Binding Source and when editing multiple records in a child form, could cause the records in the BO to go crazy and yield to the wrong data being saved, copying those records to another temporary BO and handling the data there and then re-fill the original one does the trick all the time and everybody is happy.

Of course, sometimes with this trick there could be some sort of processing penalties, but in my case it is not noticeable for the end user.  Hope with the upcoming SF V2 binding to other controls like DevExpress could be done more naturally without a binding source.

Edhy Rijo

We use scalar methods consistently within our medical software and StrataFrame provides a simple and straight forward way of executing scalare methods via the BO.  The business objects have an intrinsic method called ExecuteScalar that accepts all of the different command types or query texts depending on the immediate need.  But yes, scalar methods are very simple and easy to implement with SF.