We encountered a Touch(Devices Windows) bug several times on different devices (Surface Pro, Acer Touchmonitor, Dell All-in-One) which is really hard to pinpoint and reproduce…but its there. And its fatal.
At some point, some touches just hang and will never be deleted. sometimes the node can’t cope with that and crashes completely.
In comparison the WindowsTouch plugin never does this on the same hardware.
Ok, i had a look at the touch devices code and hell, there is so much stuff going on, saving touch events to lists etc. Probably hard to fix this…
I’ll keep using the windowstouch plugin for now since i don’t want some more teamviewer remote fixing.
guess: sort of reliable way of crashing the node was cleaning the screen with a towel ;). what if the window api send rubbish for one frame and giving your node with all the var’s and lists a headache. more touches than possible hardware touches results in windows api hickup and takes the touch node to hell ? i dunno.
do you notice any difference when using queue mode enqueue vs discard? had some hickups when deving stuff in enqueue mode. never full crashes though.
since the usage of observables is the main difference between windowstouch plugin and vvvv touch implementation (besides the subclassing, which is handled via hosting/plugininterface). the touch implementations itself are both derivations of the win 7 sdk example, at least the vvvv one i know for sure.
could not reproduce with my touchscreen using more than 10 touches.
would be interesting, if the problem is on windows side already. could you check, if wm_touch (->wparam) already reports the wrong number? if so a way to hack around that bug would probably be to add a lifetime to the touch, and killing it after a threshold of no new events (touchmove) arrived for that id.
@u7angel & @vasilis:
which windows version are you on? v4 version and does it happen with any hardware on that setup (in case you can try that).
i’m on win10 here, but i guess it’s more of an hardware issue. would only be interesting, if you have the problem remains the same between win7 and 8 or greater where wm_touch is supposedly just emulated over the new api wm_pointer where msdn explicitly states not to assume that each down has an accompaning up event