I just updated to the new version today, and discovered that one of the fixes completly broke my code. The fix I'm referring to is:

"Adapter: TypedList.GetRelationInfo() now returns a new RelationPredicateBucket object instead of an existing one. The old situation lead to errors when the GetRelationInfo() was used in a loop and a predicate was added to the PredicateExpression in the bucket. "

I'm sure it solved the above mentioned problem, but it another scenario it causes others. Let me explain.. I use the IRelationPredicateBucket as a property in many classes to reduce code redundancy as I may have a bunch of methods that tap into the same bucket/ common methods:

Private ReadOnly Property FilterBucket() As IRelationPredicateBucket
    Get
        Return NameValueList.GetRelationInfo
    End Get
End Property

I might have one method that looks like this:

Public Function GetNameValueList(ByVal MaxNumRecords As Int32, _ ByVal SortFieldIndex As AvailableSortFields, _ ByVal SortType As Int32, _ ByVal AllowDuplicates As Boolean, _ ByVal FilterFieldIndex As FilterFieldsIndex, _ ByVal FilterCompareOperator As CompareOperator, _ ByVal FilterValue As Int32) As PropertyItemsNameValue Dim SortExpression As ISortExpression = New SortExpression(SortClauseFactory.Create(CType(SortFieldIndex, PropertyItemFieldIndex), CType(SortType, SortOperator))) Me.FilterBucket.PredicateExpression.Add(PredicateFactory.CompareValue(CType(FilterFieldIndex, PropertyItemFieldIndex), CType(FilterCompareOperator, ComparisonOperator), FilterValue)) Return FetchNameValueList(MaxNumRecords, SortExpression, AllowDuplicates) End Function

I have other functions which are similar that also call the method 'FetchNameValueList':

Private Function FetchNameValueList(ByVal MaxNumRecords As Int32, _
                 ByVal sorter As ISortExpression, _
                 ByVal AllowDuplicates As Boolean) As PropertyItemsNameValue
    Me.adapter.FetchTypedList(NameValueList.GetFieldsInfo, NameValueList, Me.FilterBucket, MaxNumRecords, sorter, AllowDuplicates)
    Me.AddNameValues(Me.NameValueList, NameValuePairsIndex.NameColumnIndex, NameValuePairsIndex.ValueColumnIndex)
    Return Me
End Function

The problem lies in using the property 'Me.FilterBucket', which (in the new version) created a NEW RelationPredicateBucket object which in turn blows away the PredicateExpression I need that I added in the 'GetNameValueList' method.

Since I'm 4 months into the project, plus another project I'm working on taps into this project's business objects, I need to come up with some sort of work around to avoid a new RelationPredicateBucket object being created everytime the FilterBucket property is called.

Otherwise, I'll be stuck with the older version since the projects are too far along to go in and redo the code everywhere...

sigh... I guess one man's fix is another man's curse..

Steve

Well, first of all, the problem WAS huge, the fix solved it.

Your code relies on a bug, and I'm sorry, but I'm not going to undo a fix there is no need for that either, here's how.

' in the class definition members list:
Private _filterBucket As IRelationPredicateBucket = Nothing

' your new FilterBucket property: 
Private ReadOnly Property FilterBucket() As IRelationPredicateBucket
Get
    If _filterBucket Is Nothing Then
        _filterBucket = NameValueList.GetRelationInfo
    End If
    Return _filterBucket
End Get
End Property

The rest of the code can be the same.

Well, I wasn't asking for you to undo your fix.

However, I am going to assume that I am probably not the only one who's code has (or will if they update) been broken. There was nothing wrong with my code - the problem is that the LLGen code had a problem (in loops) and indirectly the fix for this problem broke perfectly good code that had nothing to do with loops.

I'm not an expert, nor will I pretend to be on how you coded the fix to automatically create a new RelationPredicateBucket, but it seems to me that maybe this could have been done with a parameter or overloaded thus allowing exisitng code to continue to work. For example:

TypedList.GetRelationInfo() 'Same as old way TypedList.GetRelationInfo(True) ' Creates a new object TypedList.GetRelationInfo(False) ' Does not create new object

In my humble opinion, this fix, though it solved looping problem, should have been aimed at only those situations where looping is involved, and taking into mind more backwards compatibility first..

Thank you for your new property. I will keep it in mind. I still have to go redo about 65 code files to get my project to work correctly with your new version...

Steve

Stoop wrote:

Well, I wasn't asking for you to undo your fix.

However, I am going to assume that I am probably not the only one who's code has (or will if they update) been broken. There was nothing wrong with my code - the problem is that the LLGen code had a problem (in loops) and indirectly the fix for this problem broke perfectly good code that had nothing to do with loops.

No, the code was wrong. The relationpredicate bucket returned could be altered by a given routine (you did that), which could have an affect on other code requiring a clean bucket. After adding a predicate to the bucket, the call to GetRelationInfo() didn't return the proper bucket, but one with wrong info. That's why the fix was applied.

I'm not an expert, nor will I pretend to be on how you coded the fix to automatically create a new RelationPredicateBucket, but it seems to me that maybe this could have been done with a parameter or overloaded thus allowing exisitng code to continue to work. For example:

TypedList.GetRelationInfo() 'Same as old way TypedList.GetRelationInfo(True) ' Creates a new object TypedList.GetRelationInfo(False) ' Does not create new object

In my humble opinion, this fix, though it solved looping problem, should have been aimed at only those situations where looping is involved, and taking into mind more backwards compatibility first..

No, because it would make the bug a feature and that was with this particular bug not the intention or wanted. I feel sorry you got hurt by the decision to fix it properly.

Thank you for your new property. I will keep it in mind. I still have to go redo about 65 code files to get my project to work correctly with your new version...

VS.NET won't allow you to global search/replace code over more than 1 line, but some editors will. If you have f.e. homesite laying around, you can load the code files in that editor, and global replace the property. Saves you a lot of time.

VS.NET won't allow you to global search/replace code over more than 1 line, but some editors will. If you have f.e. homesite laying around, you can load the code files in that editor, and global replace the property. Saves you a lot of time. 

... Or even with TextPad, which is a freeware text editor, you can replace all of the changes in all *.cs or vb files within seconds.