We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date

Grid Grouping Control RemoveRange produces exception

Below are two routines I''ve tried with a GridGrouping Control. The one to Hide Rows works, the second, to remove rows, doesn''t. ''This successfully hides the rows in the grid For Each range In rangeList For i = range.Top To range.Bottom grid.TableControl.Model.HideRows.Item(i) = True Next Next ''This doesn''t seem to work For i = range.Top To range.Bottom grid.TableControl.Model.Rows.RemoveRange (range.Top, range.Height) Next The hide rows routine doesn''t require a refresh or initialize. Using them after RemoveRange, they have no effect. Am I missing something? 2) How can I display the number of hidden rows for a particular group in the group summary header e.g. Items: 47 Items, 12 Hidden

5 Replies

KH Kenton Hensley June 2, 2004 01:22 AM UTC

Correction: The subject line is incorrect, RemoveRange, simply doesn''t work - there are no exceptions produced. Thank you, Kenton

AD Administrator Syncfusion Team June 2, 2004 10:10 AM UTC

Kenton, Neither RemoveRange nor HideRows will work with the grouping engine. Calling these methods bypasses the grouping engines data. If you use HideRows, the YAmount logic that is maintained by the GridTable class does not get updated. You will notice that the scrolling will then not work correctly anymore. What you should instead do is set a filter to hide rows instead of hiding rows with HideRows. See TableDescriptor.RecordFilters. And you should call Record.Delete for each record to remove records instead of calling Rows.RemoveRange. Stefan >Correction: The subject line is incorrect, RemoveRange, simply doesn''t work - there are no exceptions produced. > >Thank you, >Kenton

KH Kenton Hensley June 18, 2004 05:43 PM UTC

Thank-you very much for the explanation, Stefan. Though, can you say why these methods are available if they are known to mess cause things to get out of sync? Were they left there for some not-so-obvious reason? Good Day, Kenton

AD Administrator Syncfusion Team June 22, 2004 02:24 PM UTC

Hi Kenton, long term we''ll provide either a way to protect access to these methods or we''ll also implement them. It will happen on a case by case basis for each method. Theoretically, the GridModel should be an implementation detail only and access to it should be limited. The GridTableDescriptor and GridTable classes are the classes that you should work with. These classes utilize the GridModel so that grouping data can be rendered in a grid-like manner. The classes try to wrap existing grid functions as much as possible. However, because of the sheer amount of possibilities to customize the grid it would be not a good idea to limit access to the GridModel. There are so many scenarions where you can quickly use the GridModel for things that have not been implemented by the GridTable or where you need access to information. That''s why we are not restricting access to the GridModel. So, the reason that these method weren''t implemented fully is that we ourselves do not use those methods in GridGroupingControl. Implementations of them has less priority at this time. But long term it would sure be user friendly to have that be in a more intutitive way. Stefan

KH Kenton Hensley June 27, 2004 02:26 AM UTC

Thanks again for the explanation. It is much appreciated and helps to clear-up parts of the picture.

Live Chat Icon For mobile
Up arrow icon