I need to resize rows in a grid based on a single columns value. The xRow.PerformAutoSize() method seems to be sizing rows based on the longest text in any column (even if not visible). Is there a way to control this.
Example:
Column A has description
Column B has street address
I want to expand the row size to allow the entire Description to display on a row by row basis. Rows where the Description is blank still resize with .performautosize because the street address does not fit in the cell. I want to ignore the street address in this case.
Thanks in advance for any help or direction.
Hi,
PerformAutoSize on the row changes the row's height based on all of the data in the columns for that row. So... just to be clear, you are concerned here with the height of the row, and not the width of the column. Is that right? I ask because it seems a bit odd - it would seem to make more sense to adjust the width of the description column. But maybe your app is different.
Anyway, the only way I can think of to handle this would be to hide the description column (set column.Hidden = true) before you call PeformAutoSize on the row.
Yep - i need to adjust row sizes. if i adjust columns widths the text becomes one long run on sentence that requires too much scrolling. the sizing needs to happen only based on one column and not others. The hide trick seems plausible and is actually the source of my post - performautosize seems to take the hidden rows into account (a behavior i would not expect).
Additionally, i have noted that if the grid is not full (there is space at the bottom for more rows to be added) the performautosize does not expand the rows. if i squeeze the grid down so that some of the rows are clipped at the bottom then it magically works again.
Open to any suggestions. Have attached a screenshot illustrating the situation for clarity. some cells may not have any text and i want those to be minimum height while each other row expands to fit the text in the notes column.
Sample project attached.
Symptom 1:
Turns out the sample works with the hidden column scenario (so something else is going on in my code). Issue seems to be related to grouping - see Symptom 3
Symptom 2:
When not enough rows are present rows do not size. Provided buttons in step order to illustrate. Step 1 - fails to resize rows, Step 2 - adds blank rows, Step 3 - repeat of step 1 that now works.
Symptom 3:
If you rerun the project and this time first group by name column. note that step 3 does not work but step 5 does after the description column is hidden.
Thanks for your patience - hope this clarifies.
#2 appears to be a bug. I think this is related to an issue that was fixed a while back. I'm going to ask Infragistics Developer Support to create a case for you and write this up for developer review.
For #3, I'm not getting the same results you describe, but I think it might be because I am not doing exactly what you are doing.
Here's what I did:
1) Run the app
2) GroupBy the Name column
3) Expand the first row, so I can see the height.
4) Push button 1. This works - the row height is resized correctly.
5) Push button 2. This adds a new, collapsed, GroupByRow.
6) Here's where I get confused. Pushing button 3 at this point will do nothing, because the rows are already sized. So first, I resized the row manually, then I clicked button 3. This works just fine.
7) Clicking button 4 hides the Description column and the row is automatically autosized and shrunk down.
8) Pushing button 5 does nothing because the row is already sized.
This all seems correct to me.
BTW... I found a workaround:
Private Sub Resize_Click(sender As System.Object, e As System.EventArgs) Handles Resize.Click, ResizeAgain.Click, ResizeNotes.Click For Each rowTemp As UltraGridRow In gridData.Rows.GetFilteredInNonGroupByRows rowTemp.PerformAutoSize() rowTemp.Height += 1 rowTemp.Height -= 1 Next End Sub
Thanks. This helps both the developer support and the workaround. As for the second test, just group by Name and then hit button 1 or 3 (they are the same) and expand the group by row. May be the same bug in that the group by causes the visible rows to be compressed smaller than the available hit as in the bug you noted.
Hello BobRayes,
I have created the following case for you: CAS-102822-C1S9D3
We could continue our conversation through it.
Thank you for contacting us.
Awesome...that works for me. Feels good that it was not something obvious that I spent days trying to resolve. These workarounds you offer are great - my code is cluttered anyway so the above fix works. Also like having the option of leaving scrollbar and will keep that in my back pocket.
I appreciate your diligence and staying on top of this through resolution. You are a great company, with great products and great people. Thanks again.
Hi Bob,
I've been looking into this issue and it's actually much more complicated than it seems.
This is actually not a new issue. I went all the way back to NetAdvantage v8.1 and it was happening all the way back then and probably before. This begs the question of why no one ever noticed it before. The answer is that the issue only happens under some very specific and rare circumstances with a very specific combination of properties.
It doesn't necessarily occur when there is extra space for more rows in the grid. If you change your sample so that there are only 4 rows instead of 5, the problem does not occur. In fact, the problem does not occur with 1, 2, or 3 rows, either.
The issue actually occurs when autosizing a row causes that row to increase in size such that the grid needs a vertical scrollbar where it did not need one before. Presumably, it also happens if autosizing a row would remove the vertical scrollbar, as well, but I did not confirm that.
You can demonstrate this another way by running your sample and then double-clicking on the bottom edge of each row one at a time from top to bottom. The first 4 rows work fine because even when autosized, they fit within the visible area of the grid. But when you resize row 5, it crosses the bottom edge of the grid which means that the grid now needs a vertical scrollbar and all of the rows are re-initialized to their original height.
So the next question is... why does the grid need to re-initialize the rows in this case. And the answer is because you have set the AutoFitStyle property. Since you are using AutoFitStyle, the existence of a vertical scrollbar changes the width of the columns and when this happens, the grid has to re-initialize certain metrics. I won't go into details on why it needs to do that, because that gets REALLY complicated. :)
Anyway... I don't think there is anything we can do about this. The grid cannot know, in this case, that the metrics should not be re-initalized. It's a sort've catch-22 that it has to adjust the column widths and this causes the row heights to change.
The good news is that there are several very easy things you can do to get around it. The workaround I gave you above works because you are manually setting the height of the row. The row keeps track of this and it knows not to re-initialize itself later on. But that code is something of an ugly hack and you probably don't want it cluttering up your code.
The first and simplest recommendation I have for you is that you set RowSizing on the grid to AutoFree instead of Free. I suspect this is what you really want, anyway, since you are autosizing the rows in code. You probably didn't realize that this setting is better for what you want. Using AutoFree means that when the metrics are re-initialized, the rows are re-autosized and so it all works correctly.
If, for some reason, you must use Free instead of AutoFree, then another way to avoid this issue is to force the vertical scrollbar to display all the time.
Me.gridData.DisplayLayout.Scrollbars = Scrollbars.Vertical
This way, the grid never gets into a case where it has to recalculate the columns widths and to the row heights are not affected.