在WPF中替换Windows 7+屏幕键盘

Question

I maintain/develop a C&C application typically used on touchscreens . Most text boxes require numeric input, so most of the normal keyboard is pointless. My boss wants me to build a number pad without a keyboard for these boxes. (We do have other, alphanumeric boxes, too.) The user can select a checkbox to indicate whether the onscreen keyboard is needed.

I learned from How to disable the little touch-keyboard on Windows edit controls how to ensure that the standard Windows keyboard doesn't appear for my application. The registry 's ugly, but at least it allows me to play nice with everyone.

Since the application is already built, I decided to look into using a resource dictionary to modify my text boxes in place; see Is it possible to set code behind a resource dictionary in WPF for event handling? . By the comments this is apparently also ugly, per WPF's design.

Now I need to tell my code behind where the window (or other control) for the keyboard is. That sounds like a XAML attribute - a dependency property . Unfortunately, ResourceDictionary doesn't extend DependencyObject , so it seems this technique is unworkable.

Per WPF: Specific input textboxes (for phone numbers and such) , something like this would work if tapping would summon a keyboard with only allowed characters. Actually, that would be absolutely perfect . If only this were part of WPF and therefore integrated with the keyboard.

But maybe part of my approach is wrong? How can I get a number pad which appears when "number boxes" are selected? I really don't want to duplicate (as opposed to reference) a resource dictionary on every XAML page that involves a text box.

PS How is the question formatting?

Answer 1

I think you're doing it backwards. I also had to write my own keyboard control (with various improvements that aren't relevant here), and the way I did it was by write a new textbox control that allows me to describe the kind of keyboard I want -- numerical or standard (again, and various other properties).

Now the control itself knows where it was touched (yeah, I know), and it can contain the necessary resources to both draw itself and the popup keyboard page. You don't have to worry about anything but actually using it on your pages.