I'm just doing a review of your changes and am curious how the order change
affects the behvaior. What happens before and after these changes?
It seems like if the dwFlags can have TOUCHEVENTF_UP and TOUCHEVENTF_MOVE
at the same time changing the order will just ensure that move events get
handled correctly, but will mean that up would be missed.
I'm now a Windows developer and haven't worked with touch under Windows so
can't provide much specific guidance, so I'm just trying to sort out why
the changes are required and how they might effect things down the line - I
don't want to have one usage case fixed but another broken by merging this
On 27 June 2017 at 02:31, Anna Sokol <annaso...@gmail.com> wrote:
> Hi Robert,
> I made a slight adjustment by keeping the "else if" but by switching the
> order of "move" and "up" touch events.
> Anna Sokol
> On Mon, Jun 26, 2017 at 7:01 PM, Anna Sokol <annaso...@gmail.com> wrote:
>> Hi Robert,
>> This is a fix for win32 touch events.
>> The issue is that a TOUCHEVENTTF_MOVE and a TOUCHEVENTTF_UP can occur on
>> the same input. In the original code there was an "else if" checking first
>> for "move" and then for "up". Since both can occur at the same time the
>> "up" was being ignored. In the attached GraphicsWindowWin32.cpp file the
>> "else if" is changed to an "if" check instead so that both the "move" and
>> "up" touch events are registered.
>> Anna Sokol
> osg-submissions mailing list
osg-submissions mailing list