AutoHotkey Community

Here's what I've discovered in testing in a web application.

The keyboard works great when you use a mouse, however, after testing it on two different touch screen monitors, I get the same results. They are:

You cannot get the keys to pass to the application input field. It seems that when you press the input field, to position the cursor, and then activate the onkb, control passes to the oskb and never goes back to the application field.

You can get the oskb to pass the keys to the input field if you select the input field (to position the cursor) only if the first key you select on the oskb is selected by the mouse, then the keys can be pressed and passed to the input field by touching the screen.

When you press a key on the touch screen it keeps that key in memory and enters it again even if you select a new key. After you select the second key it passes to the input field.

Something doesn't seem to be getting released when you use the touchscreen that is when you use the mouse.

Maybe this can help. I'll be more than happy to test anything you think would we can try. Thanks.

First, some questions. Are the two touch screens the same model/manufacturer? What OS is this running on? Does the standard Microsoft osk work properly?

This may be a driver issue. The way the ahkosk works is when the mouse is over the gui, the left mouse button is mapped to a virtual key. If the script detects that the virtual key is pressed, it sends the corresponding key (the key the mouse is currently over) to the active app.
Because the mouse left button is remapped to an unused key, the click (as a mouse click) is never sent to the ahkosk gui and so it never gets the focus. Under normal circumstances, that is. In this case it seems that there is some sort of conflict or something not playing nice that is preventing normal operation. This may be because there are two things messing with the mouse functions - the touch screen and the ahkosk.

Some things to try:
In the kb.ini file, change the "safeMode" setting to "1" instead of "0". This activates the timer-based key detection instead of event-based detection.
In the same file, change "simClick=1" to "simClick=0". This disables the click simulation on the buttons.

I wish I had access to a touch screen to try to resolve this, but no longer! Try the above and see if it makes a difference. If not, I'll give you a stripped down version with just the basics and we'll see if there is anything we can do to make it work.

_________________

I will try your suggestions. One is Windows XP sp2 on a diebold touchscreen, kinda like what they use in restruants. The other is Windows 2003 enteprise server running on a HP server. This is the one running on a terminal server session.

I'll let you know if the changes have any effect. Thanks

No luck changing these values.
I did load the MS onscreen keyboard, on the XP pro SP2 computer, and it worked fine. Yours is much better and I'm sure it's something simple.

Let me know what else I can try.

Does this mean that the web app actually loses focus? Is the cursor not still blinking in the text field?

Does it make a difference if the mouse is over the gui or not? Maybe try hovering the mouse over the gui without clicking and then using the touch screen to type. Compare that to using the touch screen without the mouse over the gui.

The touch screen pointer positioning and click events may happen in such quick succession that the ahkosk does not have time to activate the left click remap before focus is lost from the web app.

I'll think on this some more.

_________________

When I activate the oskb the application looses focus. There is no blinking cursor in the input field. If I touch the input field it does have a blinking cursor, but as soon as I active the kb it's gone. Now, if I click the first character of the oskb with the mouse it transfers it to the input field just fine, and then focus does stays on the input field, however, the last key pressed on the oskb is transfered again to the input field no matter which key I press next.

I'm fairly confident that this is a conflict between the touch screen system and ahkosk--and your web app is just an innocent bystander.
I believe that the problem is because (while using the touch screen) the mouse pointer jumps to the spot where the click occurs, and the ahkosk does not have the time to turn on the left-click remap before the click actually happens. The movement to the gui and the click are simultaneous.

Let me try a variation where the left-click is always remapped and if not over the kb gui sends a normal left click instead of the virtual key. This might be the only way to absorb the click event. Also, I think that this will fix the problem of the duplicate keys.

I'll get back with you about this.

_________________

All right. I have uploaded a forked version that features the left-click remap always active. It sends the virtual key only if the mouse is over a kb gui. If the mouse is not, it sends the normal left click. The one to try is called "kb_main -TOUCH SCREEN- .ahk". If this works for you I might incorporate this into the main script with an ini setting to enable or disable. On the other hand, I might just make it the default and permanent if it seems to work and be stable. Let me know.

_________________

This didn't work on my thinclient termial and will try on the desktop touchscreen today. What happend was when I went to the oskb and pressed a key I got an error (sorry, didn't write it down). Something to do with a variable not existing. I'll get the exact error if it happnes on the desktop. Also, it actually took over the touch screen and I wasn't able to close it or do any other touchscreen functions. I ended up having to go into taskmanager and close the oksb, with it then released the screen for normal touch screen operations.

sounds like the lbutton remap was constantly on. looks to be a bit tricky to write this for a touchscreen if it is simultaneously moving to and clicking on a point, giving no time for a remap to take place. perhaps use OnMessage with wm_lbuttondown.

Micahs, I had left kiosk for a while, and only recently have decided to completely rewrite it with gdi+. I still have a lot to add, but you might be interested to take a look. its looking quite snazzy

Where can I download this from?

Hey tic, long time no read! Yeah, the remap was turned on intentionally to try to compensate for the exact problem you mentioned. I forked the project to try to solve Dallas' problem. So far it does not have my toothy grin of approval.

Dallas, please try to get the exact error. That sounds weird. Let me know how it performs on the desktop.

_________________

Regarding Dallas' terminal problem, I think I have a theory why it happened. He said it gave an error like "variable not existing."
Coincidentally, I had a similar problem when trying to run a script from SciTE's tool menu. The cause (in my case, AFAIK) is that the script is loaded without any working dir specified. This means that there is no frame of reference for the script and it gets confused. My solution was to create a launcher to act as a go-between and provide the working dir. All it does is this:Of course, once it worked I stopped. It might have been something else, too. I have no idea if this was the same problem Dallas had, but it sounds similar. He ran ahkosk with in a terminal and it might have had some unexpected side-effects. We'll have to see if it worked from the desktop.

_________________

Hi,

when I start up the keyboard it doesn't register any errors, and it sets itself fine down in my taskbar, but when I right click and choose Show nothing happens. I also note when it loads the display is a little off, the splash screens are too small. I'm on a dell laptop winXP service pack 2 1680 by 1050 pixels.

pantagruel,
I've uploaded an update.
The 'Show' menu command works properly now. Thanks for pointing that out.
What do you mean ?

Do you mean too small for the displayed text? If so, I have fixed that too (I think.) Let me know. It was caused by the disparity in our display resolutions. Mine is set to 1024x768 and it looks fine, but your higher res probably requires larger font sizes and therefore the box was too small. I changed it from 'splashtext' which needs a fixed size to 'progress' which autosizes. Thanks for the info.

_________________