Touch Screen Support
-
We have a standard Windows application running on Win2K+ OSes. One of our customers has a special requirement where he needs touch screen monitors. So, my query is regarding the compatibility of my app. Will it require any changes, or does Windows handle it by itself, or do I require any third-party software? Some basic issues like how is right-click handled are not clear to me. Can somebody provide me with some insight into this? Thanks, Krishnan
-
We have a standard Windows application running on Win2K+ OSes. One of our customers has a special requirement where he needs touch screen monitors. So, my query is regarding the compatibility of my app. Will it require any changes, or does Windows handle it by itself, or do I require any third-party software? Some basic issues like how is right-click handled are not clear to me. Can somebody provide me with some insight into this? Thanks, Krishnan
My application uses a touch screen from ELO TouchSystems[^]. With ELO, your application doesn't know that the touchscreen is installed. The touchscreen works in parallel with or in place of a mouse. The touchscreen can perform single clicks, double clicks, and drag and drop operations. There is no way to implement right click operations using the touch screen only, unless you place a touch area (a button) that means "perform a right click on the point I was last touching", which isn't very intuitive. The biggest modification you have to make to your application is to make windows and controls touchable. This usually means making them larger, and making their touchable areas obvious to the user. I've found that a 'metric' value of min(screen width,screen height)/12 is a good minimum size for a comfortable control. Push buttons are easy; just make them bigger. Radio buttons and check boxes work better if they are made larger, and they are given the WS_EX_DLGMODALFRAME extended style. This gives them a raised edge look that gives the user an indication of the touchable area for the control. Edit controls require an on-screen keyboard. I've made mine task-specific, so I use a numeric spin button, a numeric keypad, or a full alphanumeric keypad depending upon the contents of the edit control. Scroll bars and track bars are more difficult. The sizes of the Windows scroll bar controls are fixed by the system metrics values. You can increase the size, and Windows displays the scroll bar at the larger size, but it doesn't scale the arrows well, which is ugly. The thumb control for the track bar doesn't appear to resize up to a touchable size. I ended up writing my own scroll bar and track bar controls that sized appropriately.
Software Zen:
delete this; -
My application uses a touch screen from ELO TouchSystems[^]. With ELO, your application doesn't know that the touchscreen is installed. The touchscreen works in parallel with or in place of a mouse. The touchscreen can perform single clicks, double clicks, and drag and drop operations. There is no way to implement right click operations using the touch screen only, unless you place a touch area (a button) that means "perform a right click on the point I was last touching", which isn't very intuitive. The biggest modification you have to make to your application is to make windows and controls touchable. This usually means making them larger, and making their touchable areas obvious to the user. I've found that a 'metric' value of min(screen width,screen height)/12 is a good minimum size for a comfortable control. Push buttons are easy; just make them bigger. Radio buttons and check boxes work better if they are made larger, and they are given the WS_EX_DLGMODALFRAME extended style. This gives them a raised edge look that gives the user an indication of the touchable area for the control. Edit controls require an on-screen keyboard. I've made mine task-specific, so I use a numeric spin button, a numeric keypad, or a full alphanumeric keypad depending upon the contents of the edit control. Scroll bars and track bars are more difficult. The sizes of the Windows scroll bar controls are fixed by the system metrics values. You can increase the size, and Windows displays the scroll bar at the larger size, but it doesn't scale the arrows well, which is ugly. The thumb control for the track bar doesn't appear to resize up to a touchable size. I ended up writing my own scroll bar and track bar controls that sized appropriately.
Software Zen:
delete this;That's useful to know, particularly the link to ELO, who have international resellers. I like the idea of an on-screen numeric keypad, but I'm not sure I'd want to use a full alphanumeric one! Is your keypad simulating a staggered qwerty, or is it more rectangular? Don't suppose it makes that much difference to the user, since touch-typing (in the conventional sense) isn't likely to happen! Steve S Developer for hire
-
That's useful to know, particularly the link to ELO, who have international resellers. I like the idea of an on-screen numeric keypad, but I'm not sure I'd want to use a full alphanumeric one! Is your keypad simulating a staggered qwerty, or is it more rectangular? Don't suppose it makes that much difference to the user, since touch-typing (in the conventional sense) isn't likely to happen! Steve S Developer for hire
Steve S wrote: Is your keypad simulating a staggered qwerty, or is it more rectangular? The alphanumeric keyboard is a staggered QWERTY. The keyboard is a relatively simple dialog box, and the keys are pushbutton controls. One important note: the pushbutton controls are a little unusual. Normal pushbuttons issue a
BN_CLICKEDnotification when the button is released. The pushbuttons I use in my keyboard and numeric keypad issue a notification when the button is pressed. This results in a much more natural feel, in terms of the onscreen keyboard feeling like a real one.
Software Zen:
delete this;