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.
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,
I have logged this issue with our developers. I have created support case CAS-121887-Z4G5P1 to track the issue. I will update this thread once the issue has been resolved or if I have other information.
Thanks !
Hi,
Are you sure it was a windows update that triggered this behavior and not someone changing the System DPI? What is your System DPI set to currently? Can you try this with different DPI settings and let me know the results. Thanks.
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.
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.