If you became a customer of the Syncfusion Reporting Platform or the Report Viewer, Report Designer, or Report Writer components before October 2019 and have questions related to those products, you can request support through our forum system. However, please note that this support system is only for existing customers who are still using the Syncfusion Reporting Platform or its components and not for new customers looking for reporting products from Syncfusion.
For new customers or those with general reporting questions, we recommend contacting our support team at https://support.boldreports.com/, which is a separate brand created by Syncfusion for its reporting solutions. Our team will be happy to assist you with any questions you may have.
Thank you for choosing Syncfusion for your reporting needs.
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 07:29 PM UTC
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 11:35 AM UTC
>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 04:02 PM UTC
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.