Thanks for all the suggestions. I figured out the problem some days back and just posting the update here. I fixed the issue by firing a timer on each update and resetting the value when the timer gets triggered.

However, now I have to "flash" the cell based on "how" the value changed, i.e. if the value is numeric and it decreased I have to flash it with red, otherwise green. Any suggestions how to get the "previous" value in a cell just before initializeRow is fired?

i don't think i've ever used the grid to this kind of depth. pretty wild. took me 10 minutes to figure out what the cell colorizer/timer was doing.

i do agree about the cell (actually what i wanted) and the draw filter. very smooth. but what about if the underlying data that's generated (instead of a button in this case) every second or even faster. how does that work? i.e. message pump from windows to grid gets cue'd up? how would that work in this case without having lag?

ok. so i took your app and added a couple of lines of code to demonstrate the volume of it "ticks". literally doing the same thing as your button is doing it but a thousand times faster. "simulating" high volume of events.

create this at the Form1 class level

Timer t1Publisher = new Timer();

//this in constructor

 t1Publisher.Tick += t1Publisher_Tick;
            t1Publisher.Interval = 50;
            t1Publisher.Enabled = true;

//this is the code for the publisher_tick event

  void t1Publisher_Tick(object sender, EventArgs e)
        {
            int rowIndex = DummyDataCreator.RandomInt(0, this.ultraGrid1.Rows.Count - 1);
            int columnIndex = DummyDataCreator.RandomInt(0, this.ultraGrid1.DisplayLayout.Bands[0].Columns.Count - 1);
            UltraGridCell cell = this.ultraGrid1.Rows[rowIndex].Cells[columnIndex];
            this.gridCellColorizer.AddCell(cell, Color.Red, 2000);
        }

i'm actually thinking of wiring up one of our existing apps to this to see how it works.

So how's the performance?

I don't think the speed of adding items to the colorizer will be an issue in itself. The only time you might run into a performance issue with this code is if you end up building up a huge amount of cells in the colorizer at once.

Looping through the Cells every time the timer ticks could become an issue if you have thousands of cells in the list at once. If that's the case, I guess it might be possible to take an alternative approach where you don't process all of the cells all the time, but instead move the processing into the DrawFilter so that the cell is only processed when it has a UIElement on the screen. The problem with that approach is that the list could grow and grow and the cells that are out of view might never get cleared out, so it would end up eating memory. So there would have to be some other cleanup mechanism or a limit on the size of the list.

Hi Mike, i'm back and working on implementing this. i still have the code you sent and it does make sense. However my challenge is getting the colorizer to fire from the underlying datasource changing, as opposed to the click of a button like your example.

i cannot get the grid to pick up underlying datasource updates. i'm using a single typed BindingList with two bindingviews. and while the grid is definitely updating in realtime i'm not able to capture its events.

the only thing that i have working is hooking into the listchanged event of the underlying list and capture "ItemChanged", "ItemAdded" events. But i cannot figure out how to find those updated items in the grid.

what am i doing wrong?

Hi Al,

Well, you are going to be limited by what your data source exposes. I think using the ListChanged interface is probably a good idea. The ListChanged notifications pass you an index, which is an index of the row that was changed in the data source. If your grid is filtered or sorted, finding the matching row in the grid might not be simple, though, especially if you are dealing with child rows

The grid's Rows collection has method called GetRowWithListIndex that will help. On the root band, this is straightforward. You can use the index you get from ListChanged to find the correct row. For a child row, you will have to find the parent row by it's ListIndex first, and then find the child row in the child rows collection.

I don't think ListChanged gives you which field was changed, though. So the only way to determine that would be to update whatever is changing the data so that it also sends you some kind of notification with more detailed info.

OK. i thought i was. i'm able to get the notifyprop changed event to fire when i directly set a value for one of the properties . i have to wire up to each property with a shared handler.

thanks for the help

Al Maiz said:

well i'm using notifypropertychanged for all the properties in my class and hoped to listen to those. but doesn't appear to be happening when bound to data source.

I'm not sure I follow you there. If you have your own custom class and implement this interface and you are setting properties and the interface notification is not firing, then something is wrong with your interface implementation. No? Unless something in your class is bypassing the property setter or changing the property values without firing the notification. This has nothing to do with the grid or data binding. 

Al Maiz said:

i tried to capture the gridAftercELL_update event but that wasn't firing for me when the cell was updated from the underlying data source.

Yes, that's correct.

ok. yes i have just the root band. well i'm using notifypropertychanged for all the properties in my class and hoped to listen to those. but doesn't appear to be happening when bound to data source. i tried to capture the gridAftercELL_update event but that wasn't firing for me when the cell was updated from the underlying data source. i guess it only works from modifiing the data directly (by hand/code)

i've turned your gridcellcolorizer into a gridrowcolorizer which appears to work though i'm still testing. It does use the listchanged event which is a bit silly, i need to determine update vs initial load time, etc. if coloring at a cellular level is to involved then i will pass. it's not worth the effort/risk i guess.

thanks