by Michael S. Kaplan, published on 2006/11/19 09:30 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/11/19/1103636.aspx
In yesterday's Read-only, you say? Read-only to whom?, I ignored one of the important underlying issues even after explicitly mentioning its role in the disconnect between what someone might think the TextBox.ReadOnly property might do and what it actually, in fact, manages to accomplish.
The issue in question is when the .NET Framework wraps an existing technology rather than writing something new.
Now this is hardly a new issue here, it is something that caused the problems I noted twenty months ago in The WinForms DateTimePicker and MonthCalendar do not support culture settings. The reason is simple: there is no WinForms DateTimePicker or MonthCalendar as independent entities; there are just wrappers around the existing controls. Controls built by other teams for other purposes with other design philosophies and other priorities.
I suppose we are lucky that they were able to line up enough to allow wrappers to exist, now that I think about it.
Now when one talks about a feature in a product, if one piece has a 70% coverage and another related piece has a 40% coverage, it is not always easy to argue whether the feature as a whole has 40% or 70% coverage. If one wraps the other than usually it is the lower of the two numbers (unless we talk about security in which case it may be the higher of them if the weakness in one piece is still protected by the other).
But if one looks at a TextBox that wraps an EDIT control, can the TextBox really make promises in its object model that the underlying control does not support?
Well, generally speaking the answer is HELL NO, though obviously the TextBox owners can write code to shore up the support and make sure that the implied promise of the interface is represented in the final product. It is clearly the responsibility of the owners of the TextBox since the Shell folks never signed up for the features in question. Though at some point one has to worry whether the wrapper (which is of course meant to be as thin as possible to maximize performance) is going to be too heavy by virtue of too many implementation additions of that sort.
To go back to the DateTimePicker and MonthCalender example, it was simply impossible for WinForms to do anything until Windows added support for the features themselves. Until then, the disparity between the controls and other .NET globalization features was simply a limitation to document since no one wanted to rewrite the controls.
If I were feeling more cynical, I might wonder how much of the TextBox problem is caused by members of the .NET Framework owners of the TextBox simply not having East Asian/Complex Script support enabled in prior versions. Though today I am feeling more optimistic, so I'll just write it off as an unintended (and undocumented) limitation without assigning any blame. The internationalization judge will not find any malice in the decision. :-)
The problem I have with all of it is when people argue from a standpoint of ignorance of the issue -- acting like it is a simple oversight bug in the .NET control that has no excuse or reason, when it is obviously simply due to the fact that a wrapper around such a different technology is bound to have differences which can be difficult to hide. Ignoring that piece of the puzzle is rather naive in my opinion....
This post brought to you by ஔ (U+0b94, a.k.a. TAMIL LETTER AU)
JohnGalt on 19 Nov 2006 11:27 AM:
The point is that the readonly bug is a bug in Win32's Edit control. The .NET framework just continues to have the same bug. It should be fixed at the Win32 level NOT at the .NET level.
You're completely missing the point to this entire conversation. Readonly is READONLY. It is not readonly except when someone forgot to turn off the internationalization functions. This is a bug and a security hole. It should be hotfixed and immediately rolled out to all OSes that have this bug.
Having the .NET team hack a fix for it is not the solution, it's a hack that fixes a bug in future techology but doesn't fix existing technology. And no, this isn't a bug that people would actually use or expect to be there, so it's safe to fix the bug and move on.
*head shake*
Michael S. Kaplan on 19 Nov 2006 12:15 PM:
Well, except for the fact that it is not actually inserting anything and is therefore not actually a bug.
You didn't try it out first, did you? :-)
Nothing needs to be hotfixed, sorry!
Coises on 19 Nov 2006 1:11 PM:
I must be missing something. I admit to knowing nothing about .Net and little about Internationalization... I'm still gaining proficiency with the Windows API in VC6.
There must be some code, somewhere, that adds the complex script options to the context menu. Since it wouldn't make sense to add those options to every context menu in all of Windows, I must assume that *wherever* that code resides, it "knows" it is adding these items to the context menu for an Edit control. Coherently extending the Edit control model implies disabling context menu items that are meant to change the content of the control when the control is read-only. It would appear to be a bug, pure and simple: whoever wrote the extension forgot to enable or disable those items in accordance with the read-only state of the control.
The only "out" I can think of is if the menu additions are generated by "generic" code that expects them to be added only in writable contexts (knowing nothing about Edit controls in particular), while the code that's extending the Edit control has no way of knowing what it's adding, merely that it's supposed to add "something" supplied from elsewhere (so it has no way of telling that something about read-only Edit controls, nor of knowing it should either add something different or add nothing at all when the Edit control is read-only). In that case it would be more clear how the oversight could occur, but then the generic code has been misused by plugging it into a generic socket which it doesn't quite fit: ideally, both sides of the connection should be made a little "smarter" to cover the case that neither originally foresaw -- and others like it that will undoubtedly surface in the future.
Michael S. Kaplan on 19 Nov 2006 1:22 PM:
The actual cause is slightly more insidious though unrelated to the original question I was addressing in the first post or the later point I was addressing in this post.
Perhaps it could be the subject of yet another post if people are interested; it gets into the architecture of EDIT and Shell EDIT and the LPK extensions added to the latter when it largely replaced the former in Windows....
Dean Harding on 19 Nov 2006 5:48 PM:
John: It's not a security bug. I missed this post when I replied to the last one, but I explained why there.
The other thing is, if you actually try it out, what happens is that while the menu items aren't disabled, THEY DON'T DO ANYTHING (except the rtl/ltr ones, but that's a display issue only - the text isn't changed).
And, like I said in the last post, there's nothing stopping the user writing an app to send an EM_SETREADONLY message to make it non-readonly, then change the text anyway. It's just like how you can modify the style to remove the ES_PASSWORD style in a running app. If you're relying on these things for "security" then you don't understand security.
JohnGalt on 21 Nov 2006 12:14 AM:
I don't use them for security. The point is that a lot of developers I know do. I would shoot them if they worked for me, but since they don't, it's they're problem.
What MS doesn't get is that readonly to the casual programmer (which is most of them from what I can see of trying to hire good programmers) reads "read-only"'s description and tada, they're done. This is the equivalent of copy/copyf in C. MS remembers this command... copy was all through windows and resulted in buffer overuns everywhere because it copies data! Great, except when the information is too long... Yes, but normal programmers don't understand the ramifications and take the documentation literally.
Same is true about readonly. 99% of programers aren't even aware that you can send messages out of process to any handle you want.
And if they don't do anything in readonly mode, they shouldn't be there, period.
Michael S. Kaplan on 21 Nov 2006 12:20 AM:
I take it that means you are no longer demanding that "It should be hotfixed and immediately rolled out to all OSes that have this bug", right?