Bugzilla – Bug 477383
MaskedTextBox: Backspace doesn't work
Last modified: 2009-07-20 07:10:07 UTC
I can't seem to delete characters in MaskedTextBox with the Backspace key running mono-2-4 branch, r127291. This also seems to be broken on Mono 1.9.1. Steps to reproduce: 1. Compile and run attached sample. 2. Type 8005551212 or 123 or 555121, etc 3. Press Backspace Like on Windows, I would expect Backspace to delete the character to the left of the cursor.
Created attachment 273701 [details] Test Case
This should be fixed in rev 127819. Could you confirm (or not)? Thanks!
This is working now, thanks! Before I forget -- can this and #477395 be backported to mono-2-4?
hi Brad, I do as your "Steps to reproduce", it seems that characters in MaskedTextBox can't be deleted by the Backspace key. REPRO for our sample : 1. Run uia2atk/test/samples/maskedtextbox.py. 2. on sample GUI , insert characters "dfafsdfasf" or "ilikeit " into the fourth MaskedTextBox accessible. 3. Press Backspace key Output: the characters can't be deleted, until you use 'left' Key to navigate the cursor in front of the character then you can use "delete" Key to delete it. test on: mono-core-135601-1177.src.rpm mono-uia-132785-276.src.rpm uiaatkbridge-134036-662.src.rpm uiautomationwinforms-134512-668.src.rpm Revision: 135906
In rev 135925 I can use the backspce key to remove the chars in the fourth text box. Is therey any chance you could test directly with the svn version instead of the rpms? I suspect they could somehow be showing different results.
hi Carlos, The latest mono-core version is 135601, so I update the WinForm the latest version, and it still can't delete the character by enter the Backspace key, but I will retest it when the mono-core's version is updated.
Any new regarding this bug?
Carlos, I retest this bug on: mono-core-136889-1329.src.rpm mono-uia-132785-276.src.rpm uiaatkbridge-136162-663.src.rpm uiautomationwinforms-136380-671.src.rpm Revision: 136914 this problem still happens, and for the editable table cell in propertygrid has the same problem, please see the bug 513097.
Felicia, this works for me and has worked since Carlos committed his fix in February. I'm going to go ahead and close this, and the two of us can work it out over email or on IRC. I suspect you're running the 2.4 branch of mono, not mono trunk.
Hi Brad, on my computer and other co-workers' computer it still doesn't work and I still not find the reason why it shows the difference.(I'm running the mono trunk) our version is :mono-core-137213-1365.src.rpm mono-uia-132785-276.src.rpm uiaatkbridge-136162-663.src.rpm uiautomationwinforms-136380-671.src.rpm Revision: 137227 Hardware: i586 OS: openSUSE 11.1
Felicia, lets please talk about this together over email instead of spamming this bug. Thanks.
Created attachment 306046 [details] code to output some log and demostrate the root cause of the bug I can reproduce this bug easily on Felicia and Ray's notebook(both of them are Dell D630), on both mono r137183 and mono trunk. However, on other two Dell D630, I cannot reproduce the bug on them, really weird. The 4 Dell D630 all installed open suse 11.1, and the versions of "xorg-x11-server" are all 7.4-14.7.1. And I found the the bug is originated from the XLookupString P/Invoke in X11Keyboard.LookupString. (this native API just don't return the same result with same input arguments at different time) in detail: The MWF keyboard event processing procedure on X11: in X11Keyboard.TranslateMessage, the source will post a WM_CHAR message if the return value of "ToUnicode" is 1, and make the "buffer" var be the message's wParam, and in most cases the "buffer" is assigned in "ToUnicode" accroding to the value of "lookup_buffer", and the "lookup_buffer" is assigned by the "XLookupString" native API, which is called by "LookupString". And as I watched, the problem happens when "XLookupString" didn't assign the sound value to lookup_buffer, so that "ToUnicode" will not return the correct value, and the "buffer" var is not correctly set in X11Keyboard.TranslateMessage, so that the expected WM_CHAR (with wParam equals to 8, which is the code for backspace key) message is not generated, so that TextBoxBase.HandleBackspace will not be invoked. To demostrate the problem (firslty u need to find a machine which has backspace problem on MWF), u could apply the following patch on X11Keyboard.cs in SWF, and then compile and run a Textbox sample, and then hit backspace in the TextBox. On a normal machine the output will be: Evt: 22, 16, True, False, 26716165, 2397, 127, 138777296, 0, 111149117 Non-XIC: XK_BackSpace, 1, [], 24 Evt: 22, 16, False, False, 0, 0, 0, 138777296, 0, 0 Non-XIC: XK_BackSpace, 1, ], 24 UTF.LookupString: XK_BackSpace, 0, ] which means after XLookupString is invoked, the returned lookup_buffer is "/b" (/b means the backspace char) however on a problem machine, the output could be: Evt: 22, 16, True, False, 26786491, 5327, 127, 138777296, 0, 111149117 Non-XIC: XK_BackSpace, 1, [], 24 Evt: 22, 16, False, False, 0, 0, 0, 138777296, 0, 0 Non-XIC: XK_BackSpace, 1, [], 24 UTF.LookupString: XK_BackSpace, 0, [] which means after XLookupString is invoked, the returned lookup_buffer is "". Actually on Felicia's machine the returned lookup_buffer could be any kind of value, e.g. I've watched once the length of the returned lookup_buffer is 4.