In my team, we are developing an application that is using the UltraGrid with ExclusiveColScrollRegions (2 of them) to separate the "Data columns" in the left region and a custom drawn column on the right. We like that feature because we have really to distinct regions with a Separator and 2 separates horizontal scrollbars (one per region). The problem we have now is that we have to integrate the UseFixedHeaders functionality for the "Data columns" in the left region and it doesn't work well at all.
We first tried to make it work in the version 14.2.20142.2092. What happened is that we set the UseFixedHeaders to true, the pins in the column headers simply don't show up, so we can't pin them. However, the solution we tried is to avoid setting the ExclusiveColScrollRegion of the "Data columns" on the left region but keep the ExclusiveColScrollRegion set for the right custom column. By doing that we saw the pins showing up and we could pin and unpin columns. However we had a lot of issues with the Export to Excel feature and the nested rows that were not pinned correctly. Overall, after a lot of tweaking, it was working.
But now we had to pass to the version 17.1 and the behavior is not the same for some reason. With the exact same code we have, if we set the UseFixedHeaders to true, the "Data Columns" in the left region seem to disappear, but if we set them all to Fixed right after setting the UseFixedHeaders to true then we see them with their pin, however it's not something we want.
For us the best and more clean solution would be to continue setting the ExclusiveColScrollRegion of the "Data columns" in the left region and when we set the UseFixedHeaders to see the pins appear in the column headers so we can pin/unpin them, actually it's not the case even with the 17.1 version. I think in that case the export to excel and the nested rows would work correctly without us having to tweak the code and playing with their visibility order.
I tested this out with a small sample project (which I have attached here). At first, I tried setting the ExclusiveColScrollRegion on every column in the grid - some in the first ColScrollRegion and some in the second. I tried this out in 12.2, 14.2, and 17.2 and the behavior is the same in all cases. Once I assign an ExclusiveColScrollRegion to a column header, that column will not show the pin button nor will the grid allow me to fix that header.
It sounds like you only need to fix columns in the left-most ColScrollRegion, though. So if I set ExclusiveColScrollRegion on just the column I want in the right-side ColScrollRegion, everything seems to work okay for me. Once again, I tried this out in the same three versions and it seems to work for me. I'm not seeing any problem with the columns in one scrollregion disappearing.
I have attached the sample project I used here so you can run it and see if you get the same results. If my sample works for you, then there must be some other factor at work in your application and we will need to figure out what that is. Maybe you can modify my sample so that it reproduces the issue you are seeing.
Manager - Windows Forms Development
Thanks for the fast reply. That's what I thought and it was exactly the way I was trying to make the fixed headers work for the "Data columns" in the left region. We also created a small demo on our side and as you said the pins are shown correctly when the columns in the left region are not set to an ExclusiveColScrollRegion even with version 17.1. I guess we will have to dig in our application code to see what is different from the demo and then, if we find the culprit we will get back to you with what we found.
Is it possible that you made changes other than just upgrading to a new version?
Fixed headers are also not supported if you set the RowLayoutStyle to ColumnLayout or GroupLayout. So that would be one obvious thing to check.
I tested and we never set the RowLayoutStyle unfortunately, the default we use is None. However we have multiple bands hierarchy, one main band and children bands. Might it be the problem ? It worked well though with the first version we tried. We will dig into the code today by removing the most of the code we can to see how to make it work like the demo.
I can't see any reason why having hierarchical data should make any difference.
If the behavior did change between versions, then that's clearly a bug and it's something we need to look into. But we can't do that, of course, unless we can reproduce the issue first. While I was creating my sample, I look into the code a little and there were only two reasons I could see in the code why the pin buttons would not display when UseFixedHeaders is turned on. One is if the column header's ExclusiveColScrollRegion is set and the other is if you set RowLayoutStyle.
Strangely if the columns are set to Header.Fixed = True explicitly they are shown but fixed. We did try setting and resetting but that wouldnt work too.
So.. you are saying that if you set the Fixed property on the column header explicitly, the column is fixed correctly. It just doesn't show the pin? Or does it show the pin button when it is fixed?
When i set the fixed property explicitly, the column is fixed as expected and the pin is shown as fixed. But we wouldnt want fixed columns by default.
I would also add that once the column is fixed (and so the pin icon is visible and in fixed mode), if we unpin the column then it stays there, which is great. So we thought about a quick fix to pin all the columns then unpin them but it doesn't work, even with us calling the Invalidate at each step.
So once you fixed a column in code, ALL the columns show the pin? Or only the fixed one?
This sounds like there's some kind of timing issue going on there. That the grid is painting at a time when it doesn't think Fixed columns are allowed and then not getting updated when fixed headers are turned on.
Is your application using a background worker thread or creating any other threads?
Invalidate won't do anything in a case like this, but you might try calling Update on the grid at various points instead and see if that works around the issue.