Hi,
I have a hierarchical grid that contains only 2 small visible columns. When my form loads, I can see both columns of data perfectly fine, but for some reason I have a horizontal scrollbar at the bottom of my grid that scrolls very far to the right of my columns and just shows a bunch of white space.
I can't figure out why this scrollbar is appearing. I want it to only appear if I can't see the contents of my last column in the grid. I have tried playing around with many different scrollbar properties with no luck so far.
Thanks,
~Corey
Hi Corey,
If the horizontal scrollbar is much larger than it seems to need, then there must be a reason why it thinks the scroll area is so large. The obvious reason for this is that your grid has a child band that is much wider than the parent band.
What kind of data source are you using for the grid? My guess is that you are probably using a DataSet or a table in a DataSet that has a child relationship defined.
If that's the case, then you probably just need to set the ViewStyleBand on the grid to SingleBand. If that doesn't help, try setting MaxBandDepth to 1.
Mike,
My grid is a fairly simple list of team member names shown as a hierarchy. When I expand all rows, I do not see any child band that is larger than anything else.
When I set the ViewStyle to SingleBand, it does fix the scrolling, but obviously I want my bands to show.
I am binding a list of TeamMember objects to the grid. Each TeamMember object has a Team property that defines a list of child team members that report to that person. And so on.
This is how I create my list.
TypedBindingList<TeamMember> boundList = new TypedBindingList<TeamMember>(teamMembers, new List<string>() { "FormattedName", "Team" });
Any other ideas?
Okay, I see the problem, now. Your data source is recursive. This means that, as far as the grid knows, there are an infinite number of child bands. If you expand any parent row that has child rows, you will notice that the child rows are indented a bit.
By default, the grid column's widths are synchronized across all bands. So normally, you would see that the first column in your root band would have a huge width in order to account for all the indents all the way down the hierarchy. Since you didn't mention anything about the first column being huge, I assume you are probably getting around this by setting the AllowColSizing property to Free so that the column widths are no longer synchronized.
But... you still have a potentially infinite hierarchy here, so the grid's scrollbar is accounting for the lowest possible band. By default, the grid's MaxBandDepth limits you to 100 bands. So it's not actually inifinite, but it's still pretty big.
Set MaxBandDepth to something more reasonable and it will reduce the width of the scrollable area. I find that a value between 5 and 8 usually works best. A typical user will get lost any deeper than that, anyway. :)
This seems like a flaw in the grid logic. I understand that my data could result in an infinite number of bands, but why wouldn't the scrolling logic just focus on the actual visible bands and scroll as it needs to from that? It would seem like the grid would easily know if, for example, there are only actually 2 bands of data and 2 small columns and could determine the scrolling area from that.
For some reason I can't seem to set the MaxBandDepth. Something is always resetting it to 100. I am setting it before and after I bind my data, and then also farther after that at the end of the InitializeLayout event, but it still gets reset somewhere after that. I don't think I want to limit the bands though anways. Who's to say in a large company that there wouldn't be team members more than 10 levels deep? I don't think I can cut it off like that.
Is there anyway I can set the ScrollRegion width on each band myself to make the scrolling work better? I'm just trying to think of some workarounds.
CoLeichty said:This seems like a flaw in the grid logic. I understand that my data could result in an infinite number of bands, but why wouldn't the scrolling logic just focus on the actual visible bands and scroll as it needs to from that? It would seem like the grid would easily know if, for example, there are only actually 2 bands of data and 2 small columns and could determine the scrolling area from that.
The main reason is efficiency. It's a lot more efficient for the grid to figure out the maximum neccessary width of the scrollable area up front then to constantly recalculate it every time a row expands or collapses.
If you think this would be easy to track, then you could implement it. All you have to do is set the Hidden property on the band that is one level deeper than the last band that is actually displaying a row.
This is easy for the first band in the grid, but if you go any further than that, you will need to recursively walk through every row in the grid and examine the Expanded state of every row.
You could, of course, keep track of the deepest row that gets expanded by tracking the BeforeRowExpanded and BeforeRowCollapsed events. The expanded in this case is fairly simply, but in the collapsed, you can't just assume the band should be hidden, because there may be other rows that are expanded. So what you would really need to do is keep a count of the number of rows expanded at each level. But even this is not so simply, because you have to update the count when rows are added or deleted. And what about filtering or hidden rows?
It seems like it should be possible to do, but it's not simple. And it would actually be easier for you to implement this then for the grid to do it, since you can make assumptions about what grid features you have enabled and which ones you need to deal with. Implementing this in the grid itself would have to account for every possible case.
CoLeichty said:For some reason I can't seem to set the MaxBandDepth. Something is always resetting it to 100. I am setting it before and after I bind my data, and then also farther after that at the end of the InitializeLayout event, but it still gets reset somewhere after that. I don't think I want to limit the bands though anways. Who's to say in a large company that there wouldn't be team members more than 10 levels deep? I don't think I can cut it off like that.
There's nothing in the grid that ever sets (or resets) the MaxBandDepth property that I know of. I can't see why it would ever do that. My guess is that something in your code is resetting the grid layout, or maybe you are loading a Layout or a Preset into the grid at some point.
As for the limiting the Maximum depth, having a single grid with a hierarchical depth 10 levels deep is just not a good user interface. Try creating one and then expand the grid out that far and you will see it gets pretty ugly and confusing. No human user is going to be able to comfortably deal with data that complex in one screen.
Also, DataBinding in DotNet won't be able to handle this efficiently in any case. As the depth of the data increases, the number of BindingManager will increase exponentially and the performance of your application will suffer. In my experience, anything higher than 8 levels and the application will become unusable.
CoLeichty said:Is there anyway I can set the ScrollRegion width on each band myself to make the scrolling work better? I'm just trying to think of some workarounds.
No, there's no way to do that.