Windows 8.1 TouchScreen panning does not scroll window for MFC Scrollview or Win32 apps
-
Windows 7 panning via a touchscreen used to scroll the client area for MFC Scrollview apps without any special code alterations but Windows 8.1 only scrolls the windows scrollbar while the view does not get scrolled until I invalidate the whole client area explicitly. I've tried various application types and am currently using the SysMets3 example from the Petzold Win32 "Programming Windows" book CD to study the behavior without MFC handling to see what is up. Most Win32 scrolling examples are still basically the good old Petzold model when I follow the guidelines for "Legacy" apps in the Gestures and Touch MSDN technical articles so I'm assuming that approach is still supported. I've tried the disabling "Flicks" article and studied every line of code between current examples and the SysMets example and made sure there is case label for SB_THUMBTRACK and SB_THUMBPOSITION and all the other boilerplate case stuff. In the end, debugging has revealed that the section that ultimately calls ScrollWindow() never runs because the scroll position and the scroll track position come into the WM_VSCROLL handler with the same value so the follow snippet no longer runs under Window 8.1 like it used to for touchscreens on previous OS versions...
...
// Typical Switch and Case labels above which use GetScrollInfo structure with SIF_ALL..etc..si.fMask = SIF_POS;
SetScrollInfo (hWnd, SB_VERT, &si, TRUE) ;
GetScrollInfo (hWnd, SB_VERT, &si) ;// If the position has changed, scroll the window and update it
if (si.nPos != iVertPos)
{
ScrollWindow (hWnd, 0, cyChar * (iVertPos - si.nPos), NULL, NULL) ;
UpdateWindow (hWnd) ;
}
...I'm testing this app on a Windows Surface (Gen 1) with Windows 8.1 with all the Windows Updates applied and Windows 8.1 Update installed back when the machine image was created. Visual C++ 2008 Professional with all known SP's installed. I've even effectively removed all of the WM_VSCROLL code and tried returning from the WndProc with 0 and tried letting the default handler take it's course...either way the scrollbar moves anyway as if windows is setting the scroll position and scroll tracking position to the same value by some back door that breaks the ability to call ScrollWindow (or ScrollWindowEx) by traditional means (being able to determine how much to ScrollWindow(). Has anyone witnessed this and found a way around it without needing to add Touch/Gesture specific handlers in there? Thanks in advance. UPDATE: Just co
-
Windows 7 panning via a touchscreen used to scroll the client area for MFC Scrollview apps without any special code alterations but Windows 8.1 only scrolls the windows scrollbar while the view does not get scrolled until I invalidate the whole client area explicitly. I've tried various application types and am currently using the SysMets3 example from the Petzold Win32 "Programming Windows" book CD to study the behavior without MFC handling to see what is up. Most Win32 scrolling examples are still basically the good old Petzold model when I follow the guidelines for "Legacy" apps in the Gestures and Touch MSDN technical articles so I'm assuming that approach is still supported. I've tried the disabling "Flicks" article and studied every line of code between current examples and the SysMets example and made sure there is case label for SB_THUMBTRACK and SB_THUMBPOSITION and all the other boilerplate case stuff. In the end, debugging has revealed that the section that ultimately calls ScrollWindow() never runs because the scroll position and the scroll track position come into the WM_VSCROLL handler with the same value so the follow snippet no longer runs under Window 8.1 like it used to for touchscreens on previous OS versions...
...
// Typical Switch and Case labels above which use GetScrollInfo structure with SIF_ALL..etc..si.fMask = SIF_POS;
SetScrollInfo (hWnd, SB_VERT, &si, TRUE) ;
GetScrollInfo (hWnd, SB_VERT, &si) ;// If the position has changed, scroll the window and update it
if (si.nPos != iVertPos)
{
ScrollWindow (hWnd, 0, cyChar * (iVertPos - si.nPos), NULL, NULL) ;
UpdateWindow (hWnd) ;
}
...I'm testing this app on a Windows Surface (Gen 1) with Windows 8.1 with all the Windows Updates applied and Windows 8.1 Update installed back when the machine image was created. Visual C++ 2008 Professional with all known SP's installed. I've even effectively removed all of the WM_VSCROLL code and tried returning from the WndProc with 0 and tried letting the default handler take it's course...either way the scrollbar moves anyway as if windows is setting the scroll position and scroll tracking position to the same value by some back door that breaks the ability to call ScrollWindow (or ScrollWindowEx) by traditional means (being able to determine how much to ScrollWindow(). Has anyone witnessed this and found a way around it without needing to add Touch/Gesture specific handlers in there? Thanks in advance. UPDATE: Just co
Just posting what I've resorted to for anyone else reading this in the future... I decided to handle WM_GESTURE messages and provide the calls to ScrollWindow there since the scroll position and scroll handle position can be correctly processed. The caveat to all this is that it requires targeting Windows 7 and in my case, since I'm still using Visual Studio 2008 Professional, my IDE needed to bind to the Windows SDK v7.1 for the updated headers needed. Newer IDE's will already bind to a version of the Windows SDK that includes the necessary symbols for targeting Windows 7. Another caveat is that newer versions of MFC supposedly provide support for gesture via virtual member functions, but no classwizard support (as of VS 2012 Pro), blah...blah...blah, so adapt your approach as your environment dictates.