by Michael S. Kaplan, published on 2006/11/19 02:49 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/11/18/1102236.aspx
Rick asks:
We have an application written in .NET 2. In one of our controls, we use a TextBox control that’s read-only. When run on XP, the default right-click context menu for the TextBox shows the expected Cut/Copy/Paste items with Copy being the only enabled item. However, when we run the app on Longhorn Server, the context menu includes much more, including the ability to force RTL, inserting Unicode chars, etc. All these menu items are enabled – they shouldn’t be since the TextBox is read-only and have no effect.
So, my questions are:
1. Why are these menu items enabled?
2. Is there a property on the TextBox that will prevent the extra international items from being added at all (this TextBox will always be read-only)? I tried changing the IME-related properties, but they had no effect.
Thanks!
Rick
It is a funny question to ask, if you think about it.
I mean, those items are built into the EDIT control, and for me they show up in Windows XP and Server 2003 all the time.
The reason that Rick doesn't see them is that he is not installing support for East Asian and Complex Script languages, even though his users might -- and that means that perhaps there is not enough international testing going on here. :-(
Now I have talked previously about the big ticket items in those two little checkboxes (like in this post), and about how in Vista the checkboxes are gone so that support will always be there (like in this post). I have even talked about this right-click menu before (in this post, for example).
A read-only control in this case is just a .NET abstraction that the TextBox class provides in its TextBox.ReadOnly property. As the docs explain:
When this property is set to true, the contents of the control cannot be changed by the user at runtime. With this property set to true, you can still set the value of the Text property in code. You can use this feature instead of disabling the control with the Enabled property to allow the contents to be copied and ToolTips to be shown.
So clearly you can still modify the contents in code, and so can any right-click menu you add that runs code. So why wouldn't the code that the Shell adds be able to do as well?
From a developer standpoint, an application one writes has no reason to look for changes in the control; there is in fact no need to take the performance hit of binding a control that cannot change. So one could just look at the small number of changes that a user could make here as a bit of ineffectual puttering, or one could even replace the menu with one's own right-click menu and simply not support these options.
But don't just do it only on Vista, since there are some users, many of whom read this very blog, who enable international support when it is an option! :-)
This post brought to you by Ꮚ (U+13ca, a.k.a. CHEROKEE LETTER QUU)
tzagotta on 19 Nov 2006 7:27 AM:
Well, I think you are skirting the issue, which is that there appears to be a bug in the text control. Clearly, if the control is set to read-only, then this means the user shouldn't be able to change its context regardless of the method used. It is irrelevant whether the Shell is doing this-or-that - it is still wrong.
And I also disagree with your apparent conclusion that the programmer should just live with the small changes that the user might make. It is against the intention of the developer that the text can be modified.
James Hancock on 19 Nov 2006 7:41 AM:
Excellent Example...
Of why MS doesn't get UI design and security!
Readonly is readonly TO THE USER. That measn tha the USER may not change the text in any way. Thus anything that allows the user to directly change the text should be disabled. Period.
Readonly. Very simple concept of "CANNOT CHANGE" and as per the docs, programmers can chnage stuff, users can't. You're by definition changing things with these two settings.
This is a bug in the textbox control and should be fixed on all affected OSes.
Wakeup MS. This is why you suck at security still (UAC anyone?). You just don't get it.
Michael S. Kaplan on 19 Nov 2006 8:07 AM:
Hmmmmm....
Well, one could certainly note that the Shell EDIT control has no such thing, and the fact that the .NET Framework (which wraps it) *does* implies a contract that it is violating by allowing it.
In which case one can call it a .NET Framework bug.
But one can also feel the same way about other .NET wrappers, an excellent example being around the Shell common controls and common dialogs. It seems to be more the rule than the exception, and being unhappy with any one of these while ignoring that the general trend of sloppy wrappers is kind of over-idealistic and more than a bit naive.....
JohnGalt on 19 Nov 2006 11:31 AM:
The Shell Edit control does have a readonly property...
http://msdn2.microsoft.com/en-us/library/ms672100.aspx
Thus this is NOT the responsiblity of the .NET team at all, it's a bug in the common controls produced by the Shell people and should be fixed by them, because this is clearly a bug and a security bug at that.
Michael S. Kaplan on 19 Nov 2006 12:03 PM:
You assume they are setting it, right? :-)
I'm kind of iffy on it as a security bug, in any case.... especially in an EDIT control, where no one who understand edit styles in Windows would consider it to be a security setting!
Michael S. Kaplan on 19 Nov 2006 12:09 PM:
And then of course the original question was also about the RTL setting, which inserts nothing into the control and there is no way to believe that some kind of "readonly" setting should be required to block it....
Dean Harding on 19 Nov 2006 5:32 PM:
It's definitely not a security-related issue. Even if the edit control really was "read-only" the user could still write a simple app that just does a SendMessage() to the control to set the text.
If you're relying on the "read-only" (or the ES_PASSWORD style) property for proper security, then you've got bigger problems than just the user being able to set the RTL property!
Of course, it is rather strange that the .NET framework doesn't just use the ES_READONLY style (or EM_SETREADONLY message) to set the control to read-only.
Michael S. Kaplan on 19 Nov 2006 8:13 PM:
Perhaps they do, Dean -- perhaps they do. :-)
referenced by