Hi,
I've got data (from several tables) that is retrieved, loaded into a dataset, set as the datasource for UltraGridPrintDocument.Grid and displayed using the UltraPrintPreviewDialog. One field from one table in the data can be extremely long, and it can contain limited formatting ([CRLF], for example). Because of the formatting, I need to set the style of the column, and use an editorcomponent for the column. I've tried the display without doing this, and the text all appears, but [CRLF] formatting is stripped, leaving the data difficult to read. When I use the editor, the data maintains its limited formatting and is readable. The problem is that if the text is more than 32,490 characters long, none of it displays in the preview. The space is reserved for it (as in the preview may have multiple "blank" pages where that data should display), but the text is not visible.
Is this a known limitation/behavior? If so, can someone point me to the documentation for it? I looked, but I may have been looking in the wrong place.
Second, can anyone think of a way around this? (Currently, I am explicitly having to truncate the data at the limit, but because of what the data means to the reader, I'd prefer not to do that.)
Thanks,-amanda
Hi Amanda,
What kind of editor are you assigning to the EditorComponent property?
I think there is a limitation to the amount of text that the DrawString method in DotNet can handle. But I'm pretty sure the Infragistics framework handles this by just reducing the size of the string. So it should not be blank.
Also, what version of the controls are you using?
Hi Mike,
Thanks for responding. This is the editor I'm using: Infragistics.Win.UltraWinEditors.UltraTextEditor
I've tested using two different versions (one we use in a shipping released/revision cycle and one that is for our next release). Both exhibit the same behavior from what testing I've done. The versions are 7.3 (7.3.20073.38) and and 10.3 (10.3.20103.1000).
Well... I'm at a bit of a loss to explain this. If I understand you correctly, you are saying that you are assigning the UltraTextEditor the EditorComponent of the column because if you do not, then the the line breaks in your data are not displayed.
Losing line breaks usually happens when your data is using a LineFeed character only for the breaks. DotNet TextBox controls do not support this, they only support both a CarraigeReturn and a LineFeed.
By default, text fields in the grid use an EditorWithText, which is the same editor used by UltraTextEditor. So there's no way that assigning an UltraTextEditor to a column should have any effect on this at all.
So either I am misunderstanding the issue, or I am wrong about the cause of the issue in this particular case, or there is something else going on in your application besides the UltraTextEditor that is correcting the problem.
That's good to know. I've experienced a lot of odd behavior from the print preview's graphics in the past, so this is probably a bug in the PrintPreview class. But we will check it out and see if we can at least find a workaround.
Good question. I hadn't tested the actual printing. The text does print, and it prints with the expected formatting, so it appears to be a display-only issue.
You mentioned previously that the problem only occurs when you set the EditorComponent of the column to an UltraTextEditor and I previously said that this is what the column uses by default so there's no way it could have any effect.
The reason it makes a difference in this sample is that you are also setting the Style of the column to FormattedText. Setting the EditorComponent and the Style of the column at the same time is actually contradictory here. The EditorComponent will override the Style setting in this case. So setting Style does nothing.
So if you do not set the Style on the column and also do not set the EditorComponent on the column, you will see the same problem.
Anyway, I am seeing the same behavior you describe, so I'm going to forward this thread over to Infragistics Developer support so they can look into this. This may be a bug in the controls or it could be a PrintPreview bug.
By the way... does this only affect the print preview? Does the text show up if you actually print the document?
Oops. The documentation did not get included. It contained screen shots that made the upload too large.
I'm uploading a sample project. It includes documentation on a base set of test cases to reproduce the behavior. If there is a property I should/should not be setting to get the data to display, let me know.
Thanks,
amanda