Hi Frank,
I can see that light finaly went on in your handle-kaboom case :))

I was to ask u ... did u do keyboard thing for touch screens yourself
or there is some good ready code (preferably free) that can be used ?

I was aproached recently to do one cute pos 4 restoran project, so this message is realy resourcefull for me :)

I hv basic Pos4Restaurant done long time ago, but I was hoping to adopt it for touch screen operation mode. From yr message it seem to me that there will be much more things to do then just adding item lookups with large picture buttons and keayboard as facility...

Rgds++
Sergio









>>
>> Is there any programing implication to use a touch screen for
>> an application. Or is it simply the device that takes the finger moves to a mouse move ?
>>
>
>Actually Yes! There is a lot more coding necessary than You might think of at the first sight. We did a cashier-System quite some time ago. It is really great, but there *are* some issues to think of.
>
>For the touch itself there normally is nothing to do. The touch acts like the mouse. Normally the screen comes with a Driver and You can start off immediately. However from the design point of view (I don't mean the appearance) there are some issues that came up when we did it:
>
>1. We wanted acustic as well as optical feedback. Like buttons changing backcolor while they are pressed, Buttons having images as well as text nicely formated. At that time with VFP7 there was no way to make that work with normal buttons and we nedded to use an ActiveX-Button (we took DBI-Tech's). That was a lot of work as subclassing those was horrible. Finally we did that all in code and could not use the designers. With VFP 8+ You're out of that now.
>The Driver had the ability to also "Beep" when the User hits the screen. However this really was just an ugly "BEEP" *and* we did not want the Sound to play when the user hits anywhere. It should play, when he hits the button, not, when he fails to hit it.
>
>These are things You might like to consider in Your Class design.
>
>2. Another issue came up, when we added a "keyboard" like a numpad to enter the given amount etc. Your controls, like textboxes, need to be designed to work with that. *And* You need something like a "Focus-Management" as well as a "simulated Valid". Why?
>
>Imagine You do have a Textbox for the money given, as well as a numeric keypad (a programmed one with buttons). Let's say it gets activated by the process-code and now has the focus. As soon as You tip on "1" to enter the amount, the textbox looses focus, the valid fires and the focus is on the button. So the button needs to know witch object should get the information "1", at witch caret-position should this be inserted (actually the textbox should know that, but it's not the VFP-standard-behaviour, as it does not have the focus when it gets the information) and where to set the focus after that (You can't do that from the "click" to start with). Now when You hit "ENTER" to say "this is how much we got", You will need to fire the simulated Valid (or OnEnter if You like) that tells the process-logic to go on. etc.
>
>Other things like Backspace, decimal separation etc. will need to be taken care of as well.
>
>So there actually *is* a lot of code in the background necessary in order to make it look and work like "normal windows". Additionally, There still might be a keyboard and mouse under the table and You app should also work with those (at least that was our approach)
>
>So pricipally, You can start immediately *but* You will run into design-issues because You actually do have a completely different user-Interface (no keyboard, no mouse).
>
>Tell me, if You need any more help on this