Using an StackTrace object and log4net, I finally figured out why my dependent grid seem to flicker when the selection in the parent grid changes: SelectionChanged fires twice - first on MouseDown and then on MouseUp. I''m not sure whether that''s a feature or not, but I''m trying to figure out the reason behind it and how I can avoid this double firing.
BeginSelectCells() calls the event on MouseDown and EndSelectCells on MouseUp. Shouldn''t BeginSelectCells call OnSelectionChanging instead of OnSelectionChanged?
Even if that''s the intended functionality are there any good ideas on how to have SelectionChanged firing only once (10 lines of code or less :)
ADAdministrator Syncfusion Team October 4, 2004 03:29 PM
This is by design. The e.Reason value in the SelectionChanged event allows you to identify the different reasons for raising the event.
So, if you are doing something in SelectionChanged, you can test e.Reason to only perform it once. But if the flicker is from the grid''s normal processing and not your code, then it will be more difficult to try to change this behavior. Maybe overriding OnSelectionChanged and conditionally (based on e.Reason) not calling the baseclass would affect this.
JLJens LippmannOctober 5, 2004 07:35 AM
>This is by design. The e.Reason value in the SelectionChanged event allows you to identify the different reasons for raising the event.
>So, if you are doing something in SelectionChanged, you can test e.Reason to only perform it once.
Not responding on a MouseDown e.Reason avoids to fire the event down stream, and the flicker goes away. We are however extremely concerned (one might say obsessed :) with performance. We are getting several thousand message a second that need to be condensed to viewable data rate without wasting a cycle.
I would prefer actually eliminating the SelectionChanged event on MouseDown altogether.
I don''t really see the logic behind firing that event on MouseDown. Is there a way to prevent the MouseDown to fire up the SelectionChanged event?
Even more concerning for performance is the selection by shift key down. That fires the SelectionChanged event twice, once telling me that a range of one row has been selected (e.g. 7,7) then that what my current selection really is (e.g. 1,7 if I started selecting at the first data row) The e.Reason doesn''t help here because it is ArrowKey in both cases, and so we are changing child grids to first select to corresponding one row selection immediately followed by a message that we selected a range. (the even comes first from
Syncfusion.Windows.Forms.Grid.GridSelectCellsMouseController.ProcessSetCurrentCell(Int32, Int32, GridSetCurrentCellOptions
and second from
Syncfusion.Windows.Forms.Grid.GridSelectCellsMouseController.GridCurrentCellExternalMove(GridDirectionType, Int32, Boolean)
(I didn''t move anything?) )
That''s not good. Do you have any way of optimizing this. Clearly, range 7,7 is the wrong information, or do I need to go back to the Selections property to know what''s really collected?
Any samples on that are very much appreciated.
ADAdministrator Syncfusion Team October 5, 2004 12:02 PM
there is too big a chance that if we change any of this code (the way and order events are raised) that we would break existing end-user applications.
However, the selection mechanism is completely encapsulated in its own MouseController. And any MouseController in the grid can be replaced with your own implementation.
So, if the default implementation is not meeting your demands you have the option to just replace the default GridSelectCellsMouseController with your own version. You can copy/paste the original GridSelectCellsMouseController class into a file in your solution and rename it to for example CustomSelectCellsMouseController.
Now you can modify and optimize this class. You have full control over what you want to do.
Attached find a sample project with a CustomSelectCellsMouseController class and instructions how to register this custom MouseController with the grid.