Bug - Character Casing on a TextBox Control

Question

Using VS2008/SP1 and DotNet 3.5/SP1 on XP/64.

I have an unmolested TextBox in a window, with ReadOnly set to "true", and CharacterCasing set to "Upper".  When I programatically set the text value in the control, the text is NOT converted to upper case.

I have another TextBox on the same form, with ReadOnly set to "false", and CharacterCasing set to "Upper". When I type text into this control, it IS correctly converted to uppercase.

Answer 1

Hi!

I think, it's not a bug. You must be able to set the text anything you want, and the Control cannot be allowed to tamper with it. You just have to convert the string to uppercase before you set the Text property.

David

Answer 2

And I completely disagree.  By your definition, the control should also not render the text as italic if I set that property.  The control renders the text, and if I say I want uppercase text via the CharacterCasing property, then it should render it that way.

Answer 3

By changing the character casing, you alter the text, because the underlying ascii code of the letter 'a' is different from letter 'A'. If you want to compare "Alma" and "ALMA", the comparison may return that they're different strings. (Of course you can pass IgnoreCase to the stringCompareOptions.)
This does not apply to making a string italic or bold, or underlined, so these two cases are different!

Answer 4

Hi John,

you may call it a bug or a limitation, but the control acts as described:
see this http://msdn.microsoft.com/en-us/library/system.windows.controls.textbox.charactercasing.aspx

"...that specifies how manually entered characters are cased"
"This property does not affect characters that are added programmatically"

kind regards
hapevau

Answer 5

In WinForms, it acts as expected. IMHO, it's a bug if it doesn't do the same thing in WPF. WPF seems to stand for "Waning Programmatic Funtionality".

Answer 6

Don't be silly. It acts as you expected, you mean. I realise you're disappointed the control didn't behave how you wanted it to, but in most cases (this included, IMHO) WPF vastly improves the things that were wrong with windows forms.

---

Controls for WPF, Windows Forms and Silverlight at http://www.divelements.co.uk

Answer 7

It might be silly to you, but I've experience a number of Microsoft's functionality changes that resulted in my otherwise working code being rendered untenable.  The most egregious was when they changed the behavior of the CDateTime class in MFC is VS2005.  They didn't mention it to anyone until programmers starting complaining about it, and even then, they had the temerity to suggest that it was not a bug, but instead that it was our code that was at fault. After being hammered about it for about 6 months, they caved and admitted that it was probably a bad idea to change it, and they changed it back to its previous functionality.

I don't accept this particular casing behavior as an improvement or even a reasonable change.  Further, the argument that WPF is an improvement over WinForms is debatable, but that discussion is best left to not only another thread, but another forum altogether.

Answer 8

I agree that functionality changes are bad. Changing the behaviour of a class for any reason other than security is a huge no-no in my opinion, but Microsoft haven't done that. The WPF TextBox is a brand new control on a brand new platform, with no clear incentive to make its API similar to that of the Win32 textbox. I think they were right to make consistent the fact that properties that control what the user can do can be overridden by the developer. After all, if you set IsReadOnly you still expect to be able to change the Text property programmatically.

---

Controls for WPF, Windows Forms and Silverlight at http://www.divelements.co.uk