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.
Hi,
Thanks for the sample. Right now I made a tests using your sample and Lenovo X1 Carbon, but everything seems to works properly. Could you please try the same sample with different environment and let me know what is the result.
If you have any questions, feel free to write us
I've tested on a Surface Pro, and a Toshiba Kira http://www.mytoshiba.com.au/kira both exhibit the same behaviour.
Panning gestures do not work. Sometimes, intermittently, it grabs and then behaves erratically, less than 1 in 10 swipes.
All other programs on the system pan correctly, including Metro, and desktop apps like Internet Explorer.
Note both these devices have all the latest "Windows 8 Updates" loaded as of 14/08/2013.
The Surface Pro is straight out of the box, then windows updates. Nothing else on it. The Toshiba is straight out of the box, nothing else but Office on it, and the standard programs that come with the Toshiba and Norton's uninstalled.
It seems like the grid doesn't recognise the Pan Gestures, doesn't see them for some reason. If you double tap and grab the scroll bar that works, but you have to double tap to grab the thumb. You can single tap in a blank area of the scroll bar and that will also pan the grid, so it is responsive to some degree.
I don't have any other touch environments other than the Surface Pro and the Toshiba Kira. The deployment needs to happen on the Surface Pro for the client, so that is our main priority to get working. If it is an environment setting on the Surface Pro we still need to work what it is and how it can affect the WinGrid in this fashion.
On the Toshiba Kira I've managed, using the test program, to identify the random behaviour.
If you double tap the scroll bar thumb and move up and down the pan down (finger down the screen) gesture works afterwards.
However the pan up doesn't. The pan up gesture works if you pan down, but don't take your finger off the screen and pan up (move finger towards top of screen.
Note still sometimes you can't pan at all. This above behaviour is replicable most of the time however, but it's iffy.
Hope this additional information may help in finding a resolution.
I don't think that's actually a touch gesture. The double-tap and drag is the way touchpads handle a drag and drop operation. That's the same thing you described with the scrollbar thumb earlier. That's nothing to do with the control itself, it's just the way normal drag and drop is handled by windows.
You should not have to do that in order to pan or swipe. Of course, it's possible that the drivers have options to allow you to change this behavior, but if that were the case, I expect it would affect all applications, not just the grid.
You don't have to do that for any other application, do you?
It also seems unlikely that the issue would be device-specific, although I guess it's possible.
It's not device specific because the issue occurs on two different devices, a Surface Pro and a Toshiba Kira.
Maybe it's due to the high res displays and small screen size, i.e. High DPI - Toshiba is 2560x1440 4xHD
The Surface is 1920x1080 but small screen so still has a high DPI
All other applications, word, excel, internet explorer work fine as you would expect. You simply perform the gesture. The scroll bar behaves the same as it does in the grid, as you would expect.
I agree the scroll bar touch and grab isn't a touch gesture. I was just explaining the action. After doing that the pan down gesture starts to work as explained, before that, the grid responds to no gestures like the application doesn't even have focus (but it does).
Hello,
This issue has been resolved in the latest Service Release as of the date of this post.
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.
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.
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.
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.