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.
This may sound like a silly question - but is it only the WinGrid having this problem? Are you able to pan other applications on the same machine, such as Windows Explorer or IE?
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?
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.