Hi Dragan,

You are right that creating virtual keyboards are better off created as a toolbar class because focus does not leave the data control.

I have been successful in using my toolbar-based keyboard; the only thing I wish is for this keyboard toolbar object to be 'integrated' into the form where data entry takes place. Being a toolbar, it appears as a separate form, apart from the form that say captures payment details. How I wish I can drop this toolbar inside a data entry form so it will look like just one single form.

I tried the other suggestions like using labels. Sure, it does not lose focus from an entry textbox, but it fires the Valid event. This style only works for Character textboxes; does not for Numeric and Date textboxes.

I am currently trying Thomas' suggestion to use commandbuttons, but letting the form handle the keystrokes and figuring out the 'active' control. So far works for Char types, not yet for Num and Date textboxes.




>>Not sure if this the problem, but when you click on the keyboard form it is now the focus of input. So any keyboard input is now directed to this form and not the original form that you started with that has the textboxes or other input controls. I would think that you need to have a custom property at the _SCREEN or _VFP that retains the current input form (not the keyboard form). Use the Activate() event of the input form to assign it to the custom property; i.e. _SCREEN.InputForm = thisform. Each of the input controls can set a custom property in the form to give the current input control the user is entering into; use the GotFocus() or the When() events. I am not sure if the AciveControl property is reset when the form looses focus and then is again; if it is not reset, then you can use this to determine the current control for input.
>
>I think this is the main reason why the virtual keyboards go into a toolbar, because toolbar doesn't steal focus.