SFML community forums
Help => General => Topic started by: cprimesaps on September 05, 2017, 03:24:39 pm
-
Hello,
I have written an SFML application that my organization has been using for about a year using SFML. We used this application on touch screen machines running Windows 7.
However, I just purchased Windows 10 touch screen laptops, and on these machines, you have to double tap on all buttons to activate them. I have been looking through the code, and I don't see anything that jumps out at me that would make this work on older Windows 7 machines and not Windows 10 touch screen laptops.
Is this a known SFML bug or do people think that this is a code issue?
Thank you
-
The first thing to do would be to write a simple SFML app that prints what sf::Event is triggered when you single/double tap. Because we have no idea how your app and buttons work.
-
This sounds like a bug in your code. Can you share how you handle those click/touch events?
In addition, the branch feature/windows_touch (https://github.com/SFML/SFML/tree/feature/windows_touch) allows you to directly listen for actual touch events so you no longer have to rely on fake mouse clicks.
-
I know this is an old topic. But posting this here for future reference for people that run into the "double tap" touch screen issue. The problem is in your handling of the mouse.
In mouse emulation mode, the surface touch screen will send a "mouse down"+"mouse up" event in the same frame. So in 1 loop of "sf::window::pollEvent" calls you will get a down and up. So sf::mouse::isButtonPressed will never return true. And you can miss touchscreen presses if you do this on polling bases.
While polling works fine for normal mouses and certain other touch screens, it doesn't work fine for the surface.
Oddly enough, the 2nd press of a double tab does has a delay between the down and up events.
Info about this finding: http://bridgesim.net/discussion/comment/3074/#Comment_3074
-
In mouse emulation mode, the surface touch screen will send a "mouse down"+"mouse up" event in the same frame. So in 1 loop of "sf::window::pollEvent" calls you will get a down and up. So sf::mouse::isButtonPressed will never return true. And you can miss touchscreen presses if you do this on polling bases.
While polling works fine for normal mouses and certain other touch screens, it doesn't work fine for the surface.
sf::Mouse::isButtonPressed() doesn't depend on events, it's a real-time check, which yes, can potentially miss a tap (then again for a 60 fps application you'll have 16.666ms to miss the tab, which rather unlikely).
As for events, one is triggered after the other, as such you can easily handle it.