Hi Guys,
Panning Gestures in UltraGrid using Windows 8 and touch screen are not working, with latest Windows patches loaded.
As a sample to ensure it wasn't a problem with my Windows Form application I setup a UltraGrid, set a data source, filled it with dummy data, both horizontal and vertical scroll bars appear, gestures are enabled and touch control is added to the form but the grid does not pan when using panning gestures.
This is in WinForms 13.1
I was pretty sure this was working. It may be a Automatic Windows Update has caused an issue with the way UltraGrid does it?
Anyway, it doesn't work anymore.
The strange thing is you can't even "DRAG" the scroll bars. The only way to get the grid to scroll is actually click in the scroll bar to either side of the thumb. Touching and dragging the thumb doesn't work, doesn't move.
Works fine with a mouse though.
Any ideas?
Hello fikeus,
Could you please tell me what is your current build, because I made few tests using our latest available service release 13.1.20131.2060 with Win 8 and everything seems to works properly. If you are using older service release you could download the latest one from our web site: Infragistics.com -> Accounts -> My Key and Downloads -> Service Releases
Let me know if you have any questions.
Regards
13.1.20131.2060 I upgraded to ensure that was not an issue. Note please try this on a Surface Pro. This behaviour occurs on a Surface Pro and a Toshiba Kira Touch Screen. Only when using Touch Screen and your figner. If you use a Pen on the surface Pro instead of your finger the scroll bar works ok, but gestures do not work either way. To grab the scroll bar handle I worked out you have to double tap, not idea. Wouldn't matter though if the PAN gesture worked.
Also all latest Windows Updates are loaded on both.
I'm not sure if it ever worked. It may of worked initially, or appeared to, due to the intermittent, fuzzy nature of the behaviour.
With the Toshiba the DPI is set to Large Fonts, as it is a 4x Display 2560x1440. I have tried dropping the screen resolution down however and the problem persists.
On the Windows Surface Pro tablet it has the problem out of the box. Try it on a Windows Surface Pro with the test program I created and you'll see what I mean.
That's what I mean... change the system DPI from large (150%) to Small (100%) or Medium (125%) and see if it works for you then. Just dropping the resolution isn't what I meant, actually change the DPI setting. It requires a log out of windows to take hold though. The only time I've been able to reproduce this on any device (including the Surface Pro I snagged to test with) was when the DPI was set to 150% as the values we get back from the system ScreenDPI are wrong.
On the Toshiba Kirra set to 165% DPI, changing it to Medium 125% fixes the issue.
Can this be fixed? While changing the DPI is a workaround in the short term, not ideal in the long term.
We've been debating a fix for a bit but that is a workaround in the meantime. There are other options... the application can add the win32 api call to SetProcessDPIAware via pinvoke but that has pros and cons for an application as well. We are continuing to research the underlying cause with the system information being returned to us with those higher DPI settings and will keep you posted via the bug submitted on your behalf but in the meantime changing the system DPI to 100% or 125% will work or using the SetProcessDPIAware call... not that I'm a fan of either choice but they are options that should be considered and the ramifications of each workaround should be investigated before you decide to use them.
No worries. I'll let the client know. I don't believe they will have too much trouble in using 125% on the Surface Pro's via the system change.
That shouldn't affect the Tablet Based app we have created, but will probably make navigating Windows Explorer a little difficult when they need to copy files etc. I'll look into the other option of SetProcessDPIAware if it becomes bothersome for them.
Thanks for figuring out a temporary solution.
Hello,
This issue has been resolved in the latest Service Release as of the date of this post.