Hello,
the UltraGridPrintDocument should print WYSIWYG by default, that's what I thought. But printing a Grid, where all the columns are displayed correctly on screen, takes away 1 character from the values in almost every column when printed (or in the PrintPreview). Now, the values are shortened and an ellipsis is shown.
That's all I coded:ultraGridPrintDocument.Grid = this.gridReport;ultraGridPrintDocument .Print();
Is there an easy way to get WYSIWYG, instead of working around in InitializePrint or InitializePrintPreview with column.PerformAutoResize?
Thanks for your help!
The grid DOES print WYSIWYG. The problem is that the screen uses different drawing units than the printer. So the width of the column on-screen may fit the text perfectly, but when the same width is used on a printer, the text may not fit the same.
Calling PerformAutoResize on each column on the print layout accounts for this, since the print layout knows to use printer metrics and not screen metrics.
It is not working.
My Grid is in split container. i have only 3 columns.
Grid.AutofityStyle = ExtandedLastColumn.
I did steps accordint as you said. But didnt work. Following is the code
{
}
e.DefaultLogicalPageLayoutInfo.FitWidthToPages = 1;
I've gone down the route of measuring the size of the summary value.
I can measure the text size with Infragistics.Win.DrawUtility.MeasureString, but how do I get the size of the left/right margins to add to this?
First I loop through bands and columns calling PerformAutoResize.
Then I recursively go through all the childbands of every row in order to get all the SummaryValues.I build a dictionary of each column together with the widest summary found.
I then go through the dictionary and set the column widths to the max found summary width +2 where this is larger than the current columns width.
It worries me whenever I have to do anything that goes through all the rows in all the bands.It also worries me that I’m hard coding +2 for the padding.
At the stage I’m doing this there are no SummaryValueUIElement UIElements.The RowColRegionIntersectionUIElement has no Children.These don’t appear to be created until the grid is visible well after InitializeLayout.The difference between the SummaryValueUIElement Rect and RectInsideBorders would give me the padding, I think.It would also be an easier way of getting at all the summaryvalues with SummaryValueUIElement.SummaryValue.
Geting things working properly is always more important than speed, but the solution is taking ages!
eg The form with the grid loads in under 10 seconds without the autosizing and nearly 2 minutes with it.There are about 50 columns.
Is there anything that can be done to speed the following up?
column.PerformAutoResize(PerformAutoSizeType.AllRowsInBand, true);
or
int
columnWidth = column.CalculateAutoResizeWidth(PerformAutoSizeType.AllRowsInBand, true);
if (column.Width < columnWidth){ column.Width = columnWidth;}
It's happening in the form Load event and I've tried using BeginUpdate/EndUpdate which make no difference.
Is it just slow, or are there a load of events happening as I suspect?
...Just to confirm I'm doing the sizing in the form load to make things look nice when first loaded.I'm redoing the resizing on print preview like covered in this topic.
NB: There are a few thousand rows of data, as well as the 50 columns.
2 minutes seems excessive. How many rows does your grid have?
Keep in mind that autosizing a column is an expensive operation for a couple of reasons.
First, in order to resize the column, the grid has to load every row into memory. Depending on your data source and the number of rows, this can be an expensive operation. It's espeically expensive if you are using a DataSet with relationships. The DataSet is not very efficient when getting child rows.
You might be wondering why child rows matter if you are only autosizing the parent band. They matter because, by default, the parent and child columns have their widths synchronized, so they autosize together.
Fortunately, the rows only need to be loaded once, so the number of columns doesn't really matter.
The second thing is text measurement. The grid has to measure the text in every cell of the entire grid. This means that each cell object has to be created and it's appearance has to be resolved (to determine the font being used). So if you have 50 columns with 100 rows, that's 5000 cells, 5000 appearance resolutions, and 5000 text measurement operations.
This is one of the reason that the default autosizing in the grid only uses the visible rows instead of AllRowsInBand. Maybe for effiiciency, you should only autosize based on the first few rows. You can specify a number of rows to PerformAutoSize.
You would have to use a graphics object from the printer. But I don't think there's any way to get that until the PrintPage event fires, which is probably too late.
If you call PerformAutoResize on a column that is in the print layout, it will handle this for you and measure correctly for the printer, though.
How do I measure the strings in the printer context?
This is in InitializePrint/InitializePrintPreview.Do I somehow need the Graphics object.On the screen I'm doing the following:Graphics gr = reportGrid.CreateGraphics();...SizeF size = Infragistics.Win.DrawUtility.MeasureString(gr, summaryValue.SummaryText, font);
Mike Saltzman"]2 minutes seems excessive. How many rows does your grid have?
Mike Saltzman"]...in order to resize the column, the grid has to load every row into memory
Mike Saltzman"]The second thing is text measurement. The grid has to measure the text in every cell of the entire grid.
Mike Saltzman"]This is one of the reason that the default autosizing in the grid only uses the visible rows instead of AllRowsInBand. Maybe for effiiciency, you should only autosize based on the first few rows. You can specify a number of rows to PerformAutoSize.
The problem is still the print preview can't have any "..."I suppose if they're mental enough to print preview thousands of rows, then they'll have to wait!