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.
Internet Explorer Desktop, Word, etc all pan fine with using the finger, They do exhibit the same scroll bar issue though where you need to double tap to grab the scroll bar handle. However because the pan gesture works it's not an issue.
I believe it's something Windows is doing differently. Because I programmed a manual one, using an Ultra Panel, to see if I could manually trigger a pan, by capturing the mouse move event, checking if the left button is down etc. Works fine on the desktop using a mouse, click drag, pans (if the mouse is moved more than 10 pixels as a cutoff). Doesn't seem like a finger touch then drag causes a mouse down event. If the control is looking for that to determine pan, I would suspect that is why it's not working. I'm not saying it is though, it may not be, but it is a behaviour I observed while trying to work on a workaround for the issue.
On the Surface Pro or Tablet though using your finger it doesn't. Using the Trackpad it does.
Hi,
Certain gestures, like tapping and double-tapping are automatically translated into mouse messages. So it makes sense that those work - we don't have any special code to handle them, they are handled automatically.
But real gestures like panning, that don't have any mouse equivalent would not fire mouse messages. So that also seems to be working correctly in your case. I'm afraid I don't know why the gestures aren't working on the grid, though. They definitely work in our testing.
Are any of the grid's Gesture-related events firing like GestureStarted, PanGesture, GestureQueryStatus, or GestureCompleted?
Hi Mike,
I've made a test application you can download from here (includes Visual 2012 source) it's very basic.
Maybe you can have a look at it and see what is wrong.
I've tested this on the Toshiba Kira and the Pan gesture doesn't work using the touch screen. Sometimes, intermittently it does seem to respond but somewhat erratically then it stops, and doesn't matter how many times you pan up and down it doesn't move. Then by what seems like chance, it does sometimes grab.
Two finger touchpad scrolling works (using the touchpad on the notebook) as expected.
Panning works fine in Internet Explorer etc.
Test application is available for download here http://sdrv.ms/143mSC7
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.
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.