in the past i have always used the contribution windowstouch when i had to use a TouchDown-event.

As far as i know the node Touch (Device Window), which comes with the core of vvvv, does only detect the TouchDown-event once a new blob changes its xy-coordinates (finger movement) or an additional touch is detected.

Today i combined both nodes and figured out the following:
After first using the contribution WindowsTouch, also Touch (Device Window) does detect TouchDown-events immediately without moving the finger.

Can anybody reproduce this behaviour? (see attachement and follow the instructions)

I don’t exactly understand, what happens under the hood, but wouldn’t it then somehow also be possible to make this behaviour default for Touch (Device Window)? would be nice, as for my perspective it’s a missing feature!

Tested with:

  • win7, vvvv_45beta34.2_x86
  • Iiyama ProLite T2233MSC Touchscreen

Thanks for feedback,
Johannes (77.1 kB)


you’re not having the same settings on those two nodes.
PalmRejection set to false on the contribution equals WantPalm on the core node.
if you look into the code, that’s when both set the flag to value 2

and here’s the explaination the TWF_WANTPALM section:

setting this flag disables palm rejection which reduces delays for getting WM_TOUCH messages. This is useful if you want as quick of a response as possible when a user touches your application.

By default, palm detection is enabled and some WM_TOUCH messages are prevented from being sent to your application. This is useful if you do not want to receive WM_TOUCH messages that are from palm contact.

so i’d say, the core node is actually following windows defaults, while the contributions setting is more convenient

hi woei. thanks.

yeah i have read that before and of course evaluated all 3 possibilities.

but in my case non of those settings for Touch (Device Window) does make any difference regarding the TouchDown-event!

thing is, i can’t really reproduce on my touchscreen. saw a difference, but not major setting core node to wantpalm.
internally there’s not much of a difference, of both nodes. since setting the contribution seems to ‘fix’ the core one, it must be something in requesting the touch info, since that happens globally. and the only difference i found was the ambiguity in naming of that mode.

have you tried the native touch events node? or where does the suspicion come from that it’s specifically the touch-down event?

I heard from other users that it is hardware dependent whether TouchDown-events are passed to vvvv or not. They told me that they have two different touchmonitors, from which one got the TouchDown-events correctly and the other one behaving like my scenario described above…

Not sure if i got your question. I tested both nodes as used in the attached patch: windowstouch as well as the native Touch (Devices Window). TouchDown-events are always working with the contribution, but not with the native node. Windows7 itself of course does trigger a touchdown-event (e.g. when simply clicking on the desktop).

I think Woei we talked about that topic also last week. we had that issue on this 55" uhd multitouch-display and on this other iiyama screen but not with the surface pro 4 tablet.

I tested now a Dell S2340T MT Display with Windows 7 64bit and with Windows 8.1 Prof 64bit. With Win 7 i got the same issue like katzenfresser but not with Win 8.1. So maybe there is difference. So now as far as i remember, i always used the windows7 touch contrib in combination with win7 and touch devices but never with win 8 or higher…

well, there’s definitely a difference in how windows handles wm_touch btw 7 and <= 8. probably that’s why i can’t really reproduce here on win10.

still, it makes no sense, that the contribution should react differently than core if settings are set the same on both since the code literally does nothing different (besides the core node handling messages via observables).

in case you guys are investigating further, please keep an eye, if an errormessage pops up when switching the core node to wantpalm mode. and also, while core seemingly not receiving touchdowns if there is more data in the touch event split node

you’re not having the same settings on those two nodes.
PalmRejection set to false on the contribution equals WantPalm on the core node.

today i again have access to a touch monitor and was able to double-check the settings of Mode of Touch (Device Window). it seems that i earlier didn’t review the settings correctly …

"WantWalm" is the solution: touchdown-events are then detected immediately :)

thanks woei for your solution!