When test trimming is set to anything other than "None" the text in an Editor has a vertical Offset when text is trimmed.
Bug or feature?
If Features: How can I avoid this?
Many thanks.
Urs Scherrer
Hi Daniel,
I tried setting Text Trimming to other values than None and I dint see Editor text having any vertical offset when the text is trimmed. Can you please send us a sample with this issue reproduced in it? Once we receive the sample we can look further into this issue.
Please let me know if you have any questions.
Sincerely,
Sahaja Kokkalagadda
Associate Software Developer, Windows Forms
http://ko.infragistics.com/
Please see sample here: http://1drv.ms/1T9V9JU
I have investigated "TextEditor text having vertical offset when its appearance.TextTrimming property is set to anything other than None" issue, and I have asked our engineering staff to examine this further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 215795. The next step will be for a developer to review my investigation and confirm my findings or to offer a fix, or other resolution. I created a case (CAS-170576-V3W8Q0) for this issue and linked this development issue with the case. I will leave this case open and update you with any new information after the review. You can also continue to send updates to this case at any time. You can View this case in your support activity. You can view the status of the development issue connected to this case by selecting the "Development Issues" tab when viewing this case on the web site. Please let me know if you need more information.
Sincerely,Sahaja KokkalagaddaAssociate Software Developer, Windows Formshttp://ko.infragistics.com/
After reviewing “TextEditor text having vertical offset when its appearance.TextTrimming property is set to anything other than None” issue, we found that it is an issue in .Net Graphics object.
Here is the reason why it’s not feasible to fix this issue on our side. When you try to draw text with DrawString method of the Graphics class, and the StringFormat.Trimming is set to something different than StringTrimming.None, the text offsets vertically when it is trimmed. As the offset is different with different fonts and font sizes it is not feasible to fix this for all combinations of fonts / font size.
Hi Urs,
Not really. It's just a different way of drawing text. GDI Plus is the newer DotNet way to draw text. But it has a lot of problems, especially with text measurement and alignment. Newer versions of Visual Studio actually default to the old style (GDI), presumably because of the GDI Plus problems.
So reverting to GDI is a good option and will make your text drawing a lot more consistent and reliable.
Dear Mike
Many thanks for your valuable input.
The original Problem was coming form Ultragrid: Columns with trimmed text beside columns without trimmed text look ugly because text is not on the same height.
I now reactivaed trimming and placed the "UseGDIPlus.." Statement at very first line of Main Window. That works!
Does it have any other effects I should observe?
Kind regards,
Hi again,
I just realized that you posted a sample earlier in this thread and so I took a look at it. Judging by the sample, I'm guessing that your concern is when the text seems to jump when you make the form smaller.
If that's the case, then the jump seems a lot more pronounced in the UltraLabel than in the UltraTextEditor - at least on my system. But I was able to completley eliminate it by doing two things:
First, turn off WordWrap on the UltraLabel. Wrapping when you are using TextTrimming doesn't really make sense in this case, anyway.
Second, switch to GDI text rendering (instead of GDI Plus). You can do this for all of the Infragistics controls in your application by setting a static property:
Infragistics.Win.DrawUtility.UseGDIPlusTextRendering = false;
I added this line in the form's constructor right before the InitializeComponent call.
Hi,
There's nothing we can do about how the DotNet framework draws the text, nor is there any way we can determine the offset. So the only way to "solve" this would be to set up the application in such a way that things are consistent.
But... what exactly is the problem you are trying to solve here? Why is the offset a problem? Is it inconsistency across controls? Is it inconsistency within a single control? You're not changing the TextTrimming dynamically are run-time, are you?
Can you provide some screen shots or some more detailed description of exactly why the offset is a problem? If so, then perhaps we can come up with a solution that works for your application.
For UltraTextEditor this is a solution.
But it does not work for