Hi, I logged a support request on the 8th highlighting an issue that I'd consider quite basic, and it's still awaiting asignment, can someone have a quick look? It's Case Number is: CAS-33034-HBKG1R I'm posting here in case there's a known work around/
Text is rendering a different size / spacing when in edit mode (both in edit, and textbox, I assume it's a texteditor in the grid which is why I posted here.) affecting both my vista and xp machines.
It's really ruining the work flow as when people click where they want into a textbox, the text changes size, and they end up editing the wrong part of the text.
See the screen shot, 2 cells in the top left, one in edit mode, the other not, both have identical content.
Many thanks.
- Anthony
This is because of the differences between GDI and GDI+, as discussed in this knowledge base article. The long and short of it is, you can get around it by setting the control's TextRenderingMode property to GDI, although by doing that you lose the "benefits" of GDI+ text, which is basically better performance.
Thanks for the response, rather than going trought my entire app and changing the TextRenderingMode property on each control, is there a way I can make a uniform appearance throughout the app?
Is there eventually going to be a fix to this so we can use GDI Plus? Clicking in a text box or control and having the mouse cursor be in the position within the text where it was when the user clicks it is a basic, fundamental requirement and expecation of the user. Is this an infragistics specific issue or an across the board issue?
jsteinbrunner said:Is there eventually going to be a fix to this so we can use GDI Plus?
No, that seems very unlikely.
jsteinbrunner said:Is this an infragistics specific issue or an across the board issue?
This is not an Infragistics issue, it's a general problem with GDI+ and DotNet. I think if you search around the web, you will find many discussions about GDI+ and the problems associated with it.
Try using GDI and see if it adversely affects your applications performance. It may not have much of an effect at all - it depends on the application and how much text it is using.
It's a real shame that you've chosen to use the standard .net text box. Where would you find people who could make a component to replace it? :/
I read that the reason for this is that when in edit mode, your components use the standard text box, why?
This has been annoying me, I strive for good looking, high performance apps that work exactly as the user expects.
Until infragistics sorts this out you can only get 2 out of 3.
The standard TextBox in DotNet is essentially a wrapper for the TextBox built-in to Windows. We tend to take it for granted, but it actually provides quite a huge amount of functionality. It's been around for a very long time, and is a proven staple of Windows.
Creating a new control that does all the same things would be very difficult, time consuming, error-prone, and it would be time spent basically re-inventing the wheel, so to speak.
hmm,
I'm pretty sure it's not that big a task, especially when compared to some of your components.
Out of curiosity what has Telerik done for the same problem (I don't know if they've fixed it or not)?
-Anthony
Isn't that exactly what we're after? ("different behavior from the standard Windows TextBox")
I should have included with my "All due respect" that in general I enjoy and fine the infragistics controls to be very well put together. There just are some things you have to do to work around some "funkyness."
All due respect, I won't even get started on the text and mask controls. :)
Hi Anthony,
It actually is quite a big task and it would pretty much gaurantee that our control would have different behavior from the standard Windows TextBox, and less functionality.
In fact, we already have such a control - the FormattedTextEditor. :)