Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
440
PropertyChanged and filters in UltraGrid
posted

Hi,
I've found a weird behaviour with filters in the UltraGrid. In my .NET Advantage 2011.1 application, I need to listen to the PropertyChanged event of the grid to catch the filter changes because filters could be modified programmatically not firing After/BeforeRowFilterChanged.
Now let's assume we have two columns, Column 1 (C1) and Column 2 (C2), both C1 and C2 have just one FilterCondition (F1 for C1 and F2 for C2) each of which has its CompareValue (V1 and V2).
If one of the compare values, for example V2, changes programmatically, the PropertyChanged event fires correctly just once with both filters conditions F1 and F2 and the correct compare values V1 and V2.
On the other hand, if V2 is changed by the user (ex. adding a letter in the column filter row), the PropertyChanged event fires twice, first with just F1 and then with both F1 and F2!
This behaviour breaks things up causing my application to not work properly.
I've made a sample project so you may check the case and fix the issue, just remember that to replicate the behaviour, there must be at least two filtered columns and the filter must be changed by the user.

Thank you
Stefano

PropertyChangedFilters.zip
Parents
  • 469350
    Offline posted

    Hi Stefano,

    This is because of the events. When you change V2 programmatically, the BeforeRowFilterChanged event doesn't fire. The grid just makes the change to the FilterCondition and so only one PropertyChange is needed.

    If the user makes the change, then the way it work is that the grid clones the FilterConditions and passes them into the event. Then, assuming the event is not cancelled, the grid replaces the existing FilterConditions with the clones. So there are multiple property changes taking place.

    If possible, I would avoid using the PropertyChanged event. This event fires a lot, and any code you place in this event will be called very often and thus slow down your application. It's really meant to be used only as a last resort.

    What you could do, instead, is handle AfterRowFilterChanged and in the event handler, call off to another method. Then, any time you change the filter conditions in code, you simply call the same method. This gives you a centralized location where you can handle the change.

    If that's not possible for you, then another option would be to handle PropertyChanged, but don't make any assumptions about the event firing for an individual change.

Reply Children
No Data