https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/mitigation-pointer-based-touch-and-stylus-support explains how to use the 4.7 EnablePointerSupport switch and what it means.

gnaysiuol In the 4.7 announcement https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/ Microsoft says that the problem is fixed by putting this switch in configuration https://gist.githubusercontent.com/richlander/d208cba5d603daac4fd5bc9502540768/raw/51516fe6fcccd4a06612fdc042eefa3c03e9b6d0/app.config.xml and WPF will use the same touch base as UWP instead of Windows 7 WISP. But I've tried an application that uses a lot of pop-up windows and sometimes blocks in the same way.

Can someone confirm on which version of .Net the issue has been fixed? I'm still see the problem on .Net 4.6.2.

The DisableWPFTabletSupport workaroud works but is there a way to re-enable tablet support programmingly?

Do you have any news on this issue at the end? It is not clear to me if Microsoft solved it and how. I never have this issue in lab but my customer with Windows 7 is reporting it still. I would know if I will compile my solution on .net 4.6.2 on windows 7 will solve finally. Now my SW is running on windows 7 with .net 4.6.2, but compiled on 4.5.

Thank you,

A fix for this issue has been made and will be released in an upcoming version of .NET.

In reference to the original reproduction application, there was a flaw that was attempting to touch down (and up) on coordinates that were outside of the window's child border element. Even if a window is full screen, the actual size properties include window borders/chrome. Since the hit test would fail on the child element of the window, it would never propogate down to the canvas. A solution is to disable resize (thus removing the borders) or to account for them using the properties SystemParameters.ResizeFrameVerticalBorderWidth and SystemParameters.ResizeFrameHorizontalBorderWidth. Having done that, there will be no failures concerning hit testing.

Apart from that, a fix was made to account for cases where overlapped elements may have had multiple touch points on them. In these cases, it is possible the second touch point is actually hit tested to the first touch point's inserted element. When this occurs, a touch up on the first touch point will remove the element from the visual tree, leaving the second touch point associated with an element that has no parent. In this case the routed touch up will have nowhere to route to and will not be received. Visual tree changes already initiate hit tests on the dispatcher queue, but these may not be run in time (before the second touch point's touch up). To fix this, we detect the situation where a hit test is pending and will execute a hit test prior to processing a touch up for that touch point.

This issue is very unlikely to be seen in most real-world touch scenarios. Touch devices usually send a series of touch moves when a touch point is held down. These moves always initiate a hit test and it would be a very unlikely scenario that no moves were processed after the aforementioned visual tree change. However, in some specific scenarios where a touch device does not create frequent move messages this can be an issue.

In summary, most normal touch scenarios will not be broken by this specific bug and can be reliably used.

While we wait for CSS_OPrime's definitive solution I have uploaded a revised sample "AltTouchDeviceAutoCheck" which incorporates just one of the changes made in CSS_OPrime's Github version. All instances of _window.Dispatcher.Invoke are changed to _window.Dispatcher.BeginInvoke. Note that the use of a dispatcher wrapper was only added to be conservative; to make sure we are calling ReportUp on the correct dispatcher. The dispatcher wrapper should not be needed! BeginInvoke does alter the underlying API behavior and eliminates the issue with ReportUp not working. Using BeginInvoke also reduces performance by a factor of 5.

It's regrettable that CSS_OPrime is being such a meanie, but I must concede that using BeginInvoke might be an alternate workaround within a custom TouchDevice implementation. That said, none of this explains away the fact that there is a hit testing bug with ReportUp.

If anyone can get the "SimplerTouchDeviceAutoCheck" sample working without resorting to synchronization hacks, we'll have a viable solution. So far stuffing in a hit testing target is the best option aside from an eventual Framework bug fix. The trouble with all of this is that you'll only be able to get the benefit of the approaches given here if you implement your own TouchDevice.

CSS_OPrime, please provide a revised sample that shows how you resolved the underlying ReportUp problem using a simulated TouchDevice. You're assessments are inaccurate on just about everything thus far. I have uploaded a simplified version of the original code that I think you can handle. Please show us exactly where and why this simplified code is flawed. Show us the right way to construct a TouchDevice simulator that generates random touch events as the simplified sample does without it being susceptible to the ReportUp issue.

I don't have to do anything, the code is flawed amateurish nonsense, It doesn't prove anything, except the lack of knowledge of you and zdragon2002, it not clever, it's crap.
learn how to you a debug for god sake, does the possibility of two consecutive random numbers between 1 and 10 being equal really puzzle you, see if zdragon2002 wants to back you up.
did you even read anything I posted , or are you set in digging a deeper and deeper hole, you've made a fool of yourself on this. clinging to your pitiful code is just sad,
bottom line you don't have a clue.
if suggest you take your own advice and

crawl back under you're rock before the molten showers of your ignorance and arrogance rain down you like a agile lilttle RaT or ReTire.
and as you said
"Given my personal career trajectory, WinRT is the only viable option for my future. I have to help it succeed and contribute to the demise of its competitors"
your not contributing to the demise, WPF touch is not Broken Badly, you are a fraud and the only thing your contributing to is your Ego.

"Let me know when you've finished instrumenting ", " I suspect you'll be hard pressed " , .....sigh......
I been think about doing some WPF tutorials to give people getting started some better practices,
I think I'll wait a bit longer until more of you RaTs find your rocks or retire, or better yet get flattened to mush on the Cretaceous landscape.
all of a sudden the learning curve has it' benefits.

Cheers young Pinteric.

CSS_OPrime you need to prove that zdragon2002's code is invalid by showing a disparity in touch up/move/down event handling (add counters to the code showing where the code goes astray) then prove that the two line code fix does not fix the underlying problem, by then you'll have my attention.

Let me know when you've finished instrumenting the code and have a complete log showing where the original code fails. I suspect you'll be hard pressed to show incorrect log results with the two line code fix in place. If the two line code fix works, then what does that prove to you?

Sorry about that Mario, It does seem a bit odd that you post this MSDN
“The bigger problem here is that Windows 7 produces smooth curves and does not have artifacts like those of Windows 8. Worse still, you can use the Windows 7 WM_TOUCHxxx events under Windows 8 in a desktop application and get a smooth curve. Using the Windows 8 WM_POINTERxxx events produces exactly the same artifacts for your desktop application as seen in this store sample.
This is clearly a touch API bug is it not? The Windows 7 touch events should not outperform the Windows 8 touch events, should they?
Windows 8 touch handling has been advertised as being superior. When using the Windows 7 WM_POINTERxxx events under Windows 8, you get significantly more touch data points and no artifacts.
I can accept lower sampling rates, but the artifacts ... looks buggy to my eyes.”

about RT touch and this on MSDN
“The author of TouchDeviceAutoCheck has done a superb job of identifying and isolating the problem.”
In reference to WPF , let alone the ridiculous speculations and various ranting proclamations, not to mention the pitiful disable touch in WPF as a solution.
The notion that there is a flaw in the WPF message pump which is all that was being tested in the sample, is just silly and took about 10 minutes to resolve, I should have removed the test mutex’s to avoid confusion , the changes I made where very very few besides that.

I thought I laid in out simply enough for you to would get the message, I’m not trying to run anyone or anything down, or defeat anyone, merely trying to enlighten, In what I thought was a quit enough place to be discrete and convince you and anyone else that’s clinging to the hope that there is some fatal flaw in WPF, I have firsthand with every piece, there is a huge number of WPF experts, we would be screaming bloody murder if any of the nonsense that get spread by the self-proclaimed experts, over the years where real. We laugh at the “I tried WPF and let me tell you”, since the last posted wasn’t enough, I hope we can end it here peacefully,
The “Please go play in another sandbox CSS_OPrime. We're to dumb for you here”
Isn’t going to get rid of me, I will stay away from the troll infested MSDN, you Chen and Oneil, can have a grand time exchanging intelligent sounding quips and pretending to be experts. Anywhere else might get embarrassing, let it end now.

Good grief CSS_OPrime; I'm sorry I have offended you so. I thought the author zdragon2002 was very clever in how he coded up an example to demonstrate the problem, but then who am I to judge? My simpleton brain that has been coding for WPF since 2009 could only come up with a mere two lines of code to solve zdragon2002's rather tricky problem. Who in their right mind would choose such a simple path? You win CSS_OPrime. You have proven your ability to defeat us all.

(1)                device.Capture((IInputElement)RootVisual, System.Windows.Input.CaptureMode.SubTree);
                    device.ReportUp();
(2)                device.Capture(null, System.Windows.Input.CaptureMode.None);

Those two lines of code are my only contribution.

Please go play in another sandbox CSS_OPrime. We're to dumb for you here.

"Comments posted elsewhere and injected here will only serve to confuse" ? what the hell are you talking about? you use example code that generates random number to simulate touch, when A duplicate enter this list you declare it as WPF touch badly broken?, I notice you don't deny your post below or being nohone and the "The visibility of these forums is relatively minor and won't hurt WPF to a significant degree" partly because it takes 30 second most times to come up, I found this post in a link from a hack blogger quoting your ridiculous "badly broken" headline, your test is deeply flawed and very poorly constructed in almost every way. given that coupled with your previous statements, your arrogant attitude in your post, and now the cherry on top the nohone the metro troll who apparently had a community college class in philosophy(noemata/nohone so clever) want to school me on WPF touch, which I been using without issue for years , did you run you even run the app? this flashing light going on forever means WPF touch not broke!, you expect anyone to believe a world out of your mouth now? given the post below?, the only thing is true no ones paying attention here, that's why I tried handled it here,
the truth you are a unskilled store app troll, the fact you think window.Dispatcher.Invoke(DispatcherPriority.Normal, (Action) is OK, while ignorantly pushing duplicate events into the message pump while it's in effect stopped. are you really that slow?, I think the simpler explanation is probably the correct one in this case. until you have some new code to post, I would stop now, but knowing you your just getting started.

In the provided samples, a workaround for the hit testing bug may be found by enabling the FIXBUG code shown below:

#if FIXBUG
                // This is only a workaround. The touch up handler has to ignore the associated capture settings since they are bogus
                // and may even be overwriting an existing capture setting.
                device.Capture((IInputElement)RootVisual, System.Windows.Input.CaptureMode.SubTree);
                device.ReportUp();
                device.Capture(null, System.Windows.Input.CaptureMode.None);
#else
                // ReportUp fails in a seemingly random way because of failing under the hood hit testing. If you are "lucky"
                // the ReportUp will fail on the second or third call.
                device.ReportUp();
#endif

This suggests that some sort of hit testing issue is the underlying problem.

CSS_OPrime, the only motive here is to have existing WPF issues fixed. Comments posted elsewhere and injected here will only serve to confuse. I did have a quick look at your adjustments to the sample. I'm not convinced your additions of extended synchronization have any relationship to the underlying issue. I already have a working solution that does not need to resort to the approach taken in your redo, but does perform many times faster.

The visibility of these forums is relatively minor and won't hurt WPF to a significant degree, but may help to spur Microsoft to fix things. Lastly, some of the issues that we see in WPF also affect WinRT. So fixing one will likely fix the other given the code base is probably shared provided Microsoft opts to help WPF move forward a little.

https://social.msdn.microsoft.com/Forums/windowsapps/en-US/ce6d630a-b345-46ac-88ef-773704986d62/touch-responsiveness-issue-how-to-resolve-jagged-nonsmooth-lines?forum=winappswithcsharp

Touch responsiveness issue: How to resolve jagged (non-smooth) lines?
Windows and Windows phone apps > Building Windows Store apps with C# or VB






wow, is all i can say.

http://wildermuth.com/2012/11/14/Sinofsky_and_Silverlight

Noemata Sunday, August 4, 2013
"How do you monetize something that is free (Silverlight)? Selling dev tools? Or selling apps to the masses? Silverlight was the genie that had to be pushed back into the bottle. We are seeing the gradual evolution of a new software marketplace where $2 apps are the norm for now. Given that most of the big creatures out there started as slugs, ignoring the new software bottom feeders will come at the peril of those higher up in the food chain.

Given my personal career trajectory, WinRT is the only viable option for my future. I have to help it succeed and contribute to the demise of its competitors, else I might as well start planning an early retirement.

Survival of the fittest is not necessarily determined by being the strongest, smartest, or prettiest. Mammals made it by being small, agile and able to crawl under a rock when molten showers began to rain down on the Cretaceous landscape."


ok, @noemata, aka @nohone the troll from Winbeta etc., good luck on your store apps, at least you didn't use your real name like the guy on the
.net core forum who said he had giant WPF needed crossplatform , but really just got laid off from MS in Oct , his blog suggests he did some WPF back when it was in fashionable and clearly has the same motives as you, it's easy to tear thing down, you'll feel a lot better by creating something you can be proud of than this. I been asked to stay positive, you guys make it difficult.I'll leave it there for now.

@noemata,
I took a look at TouchDeviceAutoCheck and was able get it function In the way you want. I put a refactored version for you

on github (https://github.com/DSkywalker/WPFTouchTests)

the big problem was the window.Dispatcher.Invoke(DispatcherPriority.Normal, (Action)
you should almost never be calling invoke let alone with DispatcherPriority.Normal which is higher than render so you where interfering normal dispather function, which is a bad practice IMHO, window.Dispatcher.BeginInvoke(DispatcherPriority.Input, (Action) make way more sense for your case, another issue
is cause by the fact your generating random events so 2 can follow each other with the I.D and cause your logic to fail even though your Contacts.Count = can b 2 or 3, I added a test for at least a count of > 4 and was able to run at TouchProvider.BeginSimulation(this, 0.01); or 100 events/sec.
touch actually work really nice in WPF, you hardly ever need to even address it. I looked at all my touch code, it deals with the touch dynamics and then calls the same code which is in a separate method that is called by whatever keydown or mouse event provides same function. which is where I would base my testing, otherwise your testing WPF(which work just fine) not your code.

The WPF Team is investigating this issue for a fix in a future release of .NET. If you have any questions or concerns, please reach out to wpfteam@microsoft.com for more information.

For those with mission critical touch applications that absolutely have to work without issue, here is a fix to the DisableWPFTabletSupport breaking change (we couldn't wait for an official fix):

        public static void DisableWPFTabletSupport()
        {
            // Get a collection of the tablet devices for this window.
            TabletDeviceCollection devices = System.Windows.Input.Tablet.TabletDevices;

            if (devices.Count > 0)
            {
                // Get the Type of InputManager.
                Type inputManagerType = typeof(System.Windows.Input.InputManager);

                // Call the StylusLogic method on the InputManager.Current instance.
                object stylusLogic = inputManagerType.InvokeMember("StylusLogic",
                            BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.NonPublic,
                            null, InputManager.Current, null);

                if (stylusLogic != null)
                {
                    // Get the type of the device class.
                    Type devicesType = devices.GetType();

                    // Loop until there are no more devices to remove.
                    int count = devices.Count + 1;

                    while (devices.Count > 0)
                    {
                        // Remove the first tablet device in the devices collection.
                        devicesType.InvokeMember("HandleTabletRemoved", BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.NonPublic, null, devices, new object[] { (uint)0 });

                        count--;

                        if (devices.Count != count)
                        {
                            throw new Win32Exception("Unable to remove real-time stylus support.");
                        }
                    }
                }
            }
        }

This situation for WPF Touch support keeps getting worse. When you install .Net 4.5.2 Microsoft's recommended DisableWPFTabletSupport method for disabling WPF tablet support fails. So under .Net 4.5.2 there is no longer any way for an ISV to correct the underlying OS deficiencies by implementing a custom TouchDevice because it is essential for this mechanism to work.

The source code is to DisableWPFTabletSupport is shown below:

     public static void DisableWPFTabletSupport()
         {
             // Get a collection of the tablet devices for this window.
             TabletDeviceCollection devices = System.Windows.Input.Tablet.TabletDevices;

            if (devices.Count > 0)
             {
                 // Get the Type of InputManager.
                 Type inputManagerType = typeof(System.Windows.Input.InputManager);

                // Call the StylusLogic method on the InputManager.Current instance.
                 object stylusLogic = inputManagerType.InvokeMember("StylusLogic",
                             BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.NonPublic,
                             null, InputManager.Current, null);


                 if (stylusLogic != null)
                 {
                     // Get the type of the stylusLogic returned from the call to StylusLogic.
                     Type stylusLogicType = stylusLogic.GetType();

                    //stylusLogicType.InvokeMember("EnableCore", BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.NonPublic, null, stylusLogic, null);

                    // Loop until there are no more devices to remove.
                     while (devices.Count > 0)
                     {
                         // Remove the first tablet device in the devices collection.
                         stylusLogicType.InvokeMember("OnTabletRemoved",
                                 BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.NonPublic,
                                 null, stylusLogic, new object[] { (uint)0 });
                     }
                 }
             }
         }

Microsoft documents this approach at this link: http://msdn.microsoft.com/en-us/library/ee230087(v=vs.110).aspx among several others.

Specifically, the function never exits the "while (devices.Count > 0)" loop because the call that invokes the member function "OnTabletRemoved" appears to fail.

In comments I have tried adding a call to "EnableCore" thinking that this might kick start the rest to work.

How can this be resolved? Hundreds of commercial WPF applications will simply hang without any indication of the nature of their failure if this problem is not resolved ASAP.

Leaving these issues in place is a bizarre way to deemphasize WPF. The conspiracy theories around Microsoft's commitment to WPF are starting to be realized. Azure is cool, but the desktop (not the store) is still where most of the action will remain.

I just did a search with key words: "WPF Touch", it came up with 178,000 items. So why did the wpf team claim that WPF touch issues are not 'critical' and are not among 'highest numbers'?

Please do the search yourself, and take a close look.

Microsoft WPF team members:

1). Can you take a quick survey among your team to see is there ANYONE on your team NOT using a touch screen device?

2). Can you ask and let us know if anyone who uses Surface Pro 3 would NOT use touch based apps?

3). How would you suggest to Microsoft developers (us) to go about developing 'Pro' graded tablet apps? (a.k.a. IS WPF a possible framework for such apps?)

Hope you hear and listen developers who post on this and other strings of asking for WPF team to fix WPF touch issues.

Cheers,
Celerity

If you invested hundreds if not thousands of hours in your WPF application, only to find out one of your main user inputs is failing catastrophically and unpredictably, you're not alone. Please help us pressure Microsoft to fix their WPF touch support, the sooner the better. I don't even consider this a bug, it simply renders WPF unusable for any professional touch application. A serious software framework can't have one of it's main user inputs failing unpredictably.

Dear Microsoft WPF team,

This issue is so fundamental that without it being addressed asap, touch services in .NET are unusable! Isn't touch widely used by WPF developers? are you kidding us?

Any news on this. It is starting to become a big issue the more and more people are starting to use tablets and the new manipulation features of WPF.
I don't want to have to work-around a bug and re-write code if there is going to be a fix around the corner.
Can Microsoft let us have more details on why they think this issue isn't "Big" enough to address because if you search the web, you will lots of complaints about the touch lag/delay in WPF.
At least give us an easy work-around without having to create your own touch layer like this fellow developer: http://www.codeproject.com/Articles/692286/WPF-and-multi-touch

The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.

We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you.
–WPF Team.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If you require immediate assistance with this issue, please contact product support at http://support.microsoft.com/ph/1117.

https://github.com/DSkywalker/WPFTouchTests

The only workaround at present is to implement a custom TouchDevice. You will need to handle WM_TOUCHxxx messages directly. On Windows 8.x you will also need a separate execution path for some aspects of your TouchDevice and handle WM_POINTERxxx messages directly.

It's a non-trivial undertaking, but will allow you to correct the flaws detailed at the end of this posting:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/33828e1b-224a-4b73-86b5-9af949f07508/installing-net-452-breaks-microsofts-recommended-disablewpftabletsupport-method-for-disabling?forum=wpf