|
jsantos
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 87
|
I thought I would do one better and provide the 2 call stacks in one Excel file. I didn't want to exclude anything that may be helpful.
|
|
|
|
|
StrataFrame Team
|
|
|
Group: StrataFrame Developers
Posts: 3K,
Visits: 2.5K
|
OK, it looks like setting a value on the row is causing the DefaultView to raise a ListChanged event, which is being nested into the middle of the check for whether the record exists in the dictionary and adding the record to the dictionary. We can pause the changed events by using wrapping the call to NewRow() with bo.PauseChangedEvents() and bo.ResumeChangedEvents(). Give that a try and see how that works.
|
|
|
|
|
Edhy Rijo
|
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Hi JSantos and Ben, One thing to keep in mind is that in your msd BO you have a filter condition but when you add call msd.NewRow() that new record will not show up due to the filter condition, so you should temporarily remove the filter, add the new row, add a value to msd_PrimaryRecID that match the filter then apply the filter. Working with filtering in BO can be very tricky and cause a lot of headache if your code don't take then in consideration, specially when looping. So I would code your loop like this:
Do
msd.NewRow()
msd._PrimaryRecID = Me.recid
msd.Filter = String.Format("msd_PrimaryRecID = '{0}'", Me.recid)
.... continue with your code
Again, I don't see your whole code, but the filter may be the one causing you problems.
Also to be honest, I don't quite understand why you are applying a filter to the msd BO since you are adding a new record inside the loop. I am assuming that the BO you showing here is not msd.
Edhy Rijo
|
|
|
|
|
StrataFrame Team
|
|
|
Group: StrataFrame Developers
Posts: 3K,
Visits: 2.5K
|
Yep, Edhy, the WPF ICollectionView and IEditableCollectionViewAddNewItem models take care of adding/editing an item when the view is sorted/filtered by holding the item to the side until the add/edit of the item is finalized through CommitAdd/Edit(). There's even a NewItemPlaceholderPosition to allow you to specify whether you want the blank new-item row on the top or the bottom. Sounds great in theory, but the implementation has been a bugger because you have to have a custom enumerator that return the "fake" or shifted items.
|
|
|
|
|
Edhy Rijo
|
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Yes, Ben you are right. I remember long time ago when I was starting with SF having this sort of weird outcome when using filter/sorting on a BO and adding new rows or deleting current one. Careful is a most during those situation, but I must also say that I love the BO Filter/Sorting features since they have allowed me to deal with some custom processing in an easy way, again as long as I remember that I using a filter or sort later on 
Edhy Rijo
|
|
|
|
|
jsantos
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 87
|
Thanks both of you your help. Unfortunately neither suggestions worked. I even tried PausingChangedEvents for the parent as well as the business object that I am trying to add to. Edhy, to be honest I have no idea why the filter is there myself that's the way the code was when I picked up this issue. It is looping through the parent BO to get information and creating msd records (child BO). OK while typing this message and based on your comments Edhy I decided you know what let me search the entire file where msd.Filter is being used maybe to comment them all out, like you I just don't understand the purpose of filtering the child object at the point while adding to it. There is 0 comments in this code except for this I just found. Look at the Try Catch error handler comment. Lovely. If ptmd.MoveFirst Then Do msd.Filter = "msd_PrimaryRecID = '" & Me.recid & "'" Try msd.NewRow() Catch ex As ArgumentException 'I32065, "An item with the same key has already been added." error 'ArgumentException occurs when there is more than one predecessor coming from product template 'This error does not seem to be causing functional instability, we can just ignore it for now End Try msd.msd_DependencyType = ptmd.DependencyType msd.msd_LagTime = ptmd.LagTime msd.msd_DependentTaskNumber = CShort(ptmd.DependentTaskNumber + Me._TaskDiff) '-- Dependent RecID will be set in milestone form update Loop While ptmd.MoveNext End If So what I am going to do right now is try commenting out all the filtering used on the msd BO and see what effect it has. I will be right back.
|
|
|
|
|
jsantos
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 87
|
OK so when I commented all filtering of the msd BO I get no error at the .NewRow call. But when I check any of the properties of the msd BO I get "MicroFour.StrataFrame.Business.BusinessLayerException: The CurrentRow for table '[dbo].[sch_MileStonesDependencies]' could not be evaluated because the CurrentRowIndex is out of range. Business object record count: 0. CurrentRowIndex: -1." After .NewRow shouldn't there be at least one record in the BO? Still investigating.
|
|
|
|
|
StrataFrame Team
|
|
|
Group: StrataFrame Developers
Posts: 3K,
Visits: 2.5K
|
Yes, there should be at least 1 record in the BO after .NetRow() if there is no filter on it. There is a property on the primary business object that will auto-filter child business objects. You might check the value of the .Filter in the watch window before the call to .NewRow() and see if something else, like the parent BO, is setting it.
|
|
|
|
|
jsantos
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 87
|
Ok more info. I stepped through the code in .NewRow() and actually there is an error occurring in the procedure call OnSetDefaultValues, which raises the SetDefaultValues event. Thanks Ben I will take a look at the filter at the .NewRow call and take a look at that property.
|
|
|
|
|
jsantos
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 87
|
Awesome!! So following both your comments it looks like this filtering is causing the issue. Just before the NewRow call I checked the filter and it was set so I set it to empty string at the beginning of the procedure and that seems to have done the trick. NO MORE ERRORS!!! (at least for now) , yippeee. Thanks to you both Edhy and Ben.
|
|
|
|