Add RowsChanged, ColumnsChanged event to ValueTypeMatrix<T>

[abeham]

Parameter binding branch:

Currently the only event that identifies a change in the matrix dimensions is Reset. Additionally RowsChanged and ColumnsChanged should be fired so that an automatic binding mechanism can be applied that takes the number of rows into account.

[mkommend]

Added ColumnsChanged and RowsChanged event in IStringConvertibleMatrix and all implementing classes with r5150.

[mkommend]

Please forward the ticket to swagner after your review is finished.

[abeham]

RunCollection

• ItemRemoved should fire RowsChanged as well.
• From the point of view of an IStringConvertibleMatrix AddParameter, AddResult, RemoveParameterName, and RemoveResultName may also result in a change to the value returned by the Columns property.

[mkommend]

Added OnRowsChanged in RunCollection.OnItemsRemoved with r5152.

[mkommend]

From the point of view of an IStringConvertibleMatrix AddParameter, AddResult, RemoveParameterName, and RemoveResultName may also result in a change to the value returned by the Columns property.

The listed methods are only called from OnItemsAdded, OnItemsRemoved, etc. which handle the firing of events to improve the performance of the RunCollection.

[abeham]

Okay. As per your request, I'll forward this to swagner.

swagner please have a look at the events that are fired. As discussed with mkommend, there are *NameChanged and *Changed events that are fired right after another. Unfortunately I don't have a general recipe myself in situations where multiple events ought to be fired. From my point of view, I think we should hide e.g. the row name change, when the row changes itself, so that a RowsChanged event dominates a RowNamesChanged event. It should be pretty clear that when the rows have changed, the names need to have changed as well.

[swagner]

Replying to abeham:

swagner please have a look at the events that are fired. As discussed with mkommend, there are *NameChanged and *Changed events that are fired right after another. Unfortunately I don't have a general recipe myself in situations where multiple events ought to be fired. From my point of view, I think we should hide e.g. the row name change, when the row changes itself, so that a RowsChanged event dominates a RowNamesChanged event. It should be pretty clear that when the rows have changed, the names need to have changed as well.

I am not so happy with the idea to suppress events, as then it might become quite cumbersome to understand which events are fired in which cases. Furthermore, consider the case when someone is just interested in name changes. If we suppress some of the name changed events, handlers for both events have to be registered which might not be intuitively clear. Therefore I would recommend to fire multiple events, as long as we do not run into any performance problems.

[swagner]

I reviewed r5150 and r5152 and do not have any additional comments. Thanks.