I discovered, that characters like 'ě', 'š', 'č', 'ř', 'ž' don't
trigger EVT_KEY_DOWN and EVT_CHAR so there is no way to handle such
keys properly. They, on the other hand, do trigger EVT_TEXT and they
normally get written into the text control.
This is particularly a problem in combination with masked controls
from wx.lib.masked. The masked controls don't have a chance to handle
those characters so the characters get written into the field and the
result is, that the mask is corrupted and the mask handling code gets
confused.
This happens with wx-2.8-gtk2-unicode on Linux.
It is possible to reproduce the problem within wx demo: "More Windows/
Controls" -> "MaskedEditControls". Typing 'ě' or pasting it into any
of the fields with a numeric mask, such as "Phone No" or "Social Sec#"
corrupts the field's behavior with no chance to get back to the
correct behavior.
Is there any known work around or a chance it will be fixed?
There has been some work in wxWidgets trunk over the past few days that sounds like it might be related to this issue.
···
On 1/27/12 4:49 AM, TC wrote:
Hello,
I discovered, that characters like 'ě', 'š', 'č', 'ř', 'ž' don't
trigger EVT_KEY_DOWN and EVT_CHAR so there is no way to handle such
keys properly. They, on the other hand, do trigger EVT_TEXT and they
normally get written into the text control.
This is particularly a problem in combination with masked controls
from wx.lib.masked. The masked controls don't have a chance to handle
those characters so the characters get written into the field and the
result is, that the mask is corrupted and the mask handling code gets
confused.
This happens with wx-2.8-gtk2-unicode on Linux.
It is possible to reproduce the problem within wx demo: "More Windows/
Controls" -> "MaskedEditControls". Typing 'ě' or pasting it into any
of the fields with a numeric mask, such as "Phone No" or "Social Sec#"
corrupts the field's behavior with no chance to get back to the
correct behavior.
Is there any known work around or a chance it will be fixed?