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.

Context: MFC MDI CScrollView app, targeting Windows 7 When handling a WM_GESTURE command, specifically when GESTUREINFO.dwID = GID_PAN, and attempting to call UpdatePanningFeedback() to provide "over-panning" feedback when user attempts to pan beyond the scroll limits, the entire application window moves instead of the client area of the windows handle provided...

// In this case m_hWnd is my CScrollView derived view class member windows handle.
UpdatePanningFeedback(m_hWnd, 0, yOverpan, gi.dwFlags & GF_INERTIA);

Does anyone know if there is an alternative way to achieve the effect of the "over-panning" (that visual feedback that seems like your trying to stretch the client area beyond it's limits like a rubberband) only in the client area of the CScrollView window?

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

try statically linking to the C-Runtime, ATL, and MFC... -Change C++/Code Generation/Runtime Library from /MD to /MT. -Change General/Use of ATL/ to "Static Link to ATL" -Change General/Use of MFC/ to "Use MFC in a static Library"

Do you actually use

hercgui_addr

later in the code? I find that if I'm looking at optimized assembly output that if I don't actually use the value for something, the extra processing code can get discarded. At a minimum, you can dump the value to console or screen to make sure the code remains in the optimized assembly output.

pasztorpisti wrote:

What do you mean on "virtualness" of the class that implements the interface?

Sorry, just meaning that once declared virtual in base class, a method is virtual for all "derived" classes.

Thanks for taking the time for such a detailed response. It got me thinking about it some more and I believe I now understand why it's there. I was just hoping that the vtable wasn't even needed if the instantiated classes didn't explicitly declare anything virtual. I was hoping the __interface rules and requirements could all be enforced at compile time and the need for the vtable in the derived class could be discarded in my scenario. Do you think if a true interface keyword existed in the C++ standard, that the virtualness of the interface would not be implied in the classes that "implement" the interfaces. Do "deriving from the interface" and "implementing the interface" mean the same thing?

Thanks for responding. I guess my confusion is if __interface hints to the compiler that the base class will never be instantiated, even though __interface supposedly makes the methods pure virtual, I was hoping that the interface rules were being enforced at compile time and the virtualness of the base class declarations would not propagate up to the derived class, unless of course the derived class explicitly declared something virtual. I know that kinda flies in the face of the normal rules for virtual but I was hoping there was a way to get interface rules enforcement without literally applying the virtual rules unless explicit outside of the interface. I was hoping that CSample, in this case, would be treated at runtime like it did not have a base class and did not have any virtual methods, and thus the compiler would discard the vtable for it as well. Is the vtable really needed (in this scenario)?

I'm just trying to understand the Microsoft specific modifier __interface. According to the MSDN, "__interface implies the novtable __declspec modifier." However, when I try to mock up code to try an verify this, Visual Studio 2008 still suggests the vtable pointer is present?

__interface ISample
{
bool Next();
bool Prev();
};

class CSample : public ISample
{
public:
bool Next()
{
return false;
}

bool Prev()
{
    return false;
}

};

Am I misunderstanding what MSDN is trying to convey or am I just doing something wrong. In a nutshell, just trying to see if it's possible to enforce interface rules without needing the vtable overhead if only deriving from __interface declarations. I understand that this would not be portable code.

Rob Grainger wrote:

I thought macro's were generally regarded as bad style in modern C++.

Just out of curiosity, can you rewrite a macro like ASSERT as an inline and still have DebugBreak() take you to the offending line of code instead of the call to DebugBreak() in the inline function/method? Every time I try to embrace the idea of discarding the idea of MACROS, I find too many gems in MFC that I struggle to find an equivalent for in a macro free zone.

Nemanja Trifunovic wrote:

and downright dangerous (Alexandrescu

I'm glad I'm not the only one who thought that.

Social Distortion, Tool, and Disturbed

Albert Holguin wrote:

There was an article about this not too long ago stating the intent for Visual Studio to keep supporting desktop application development, which means it will keep getting supported in Windows

I had seen something about that but it almost sounded like it was discussing running it on and targeting some previous versions of Windows. That apparently confused me enough to cause some concern. thanks for reponding.

I keep seeing this "note" as I browse through the MSDN for Visual C++ 2012 (i.e. MFC classes, ATL, etc...) What exactly does this imply for a Native Code programmer? (The more I read about the WinRT, the more confused I get) Will a traditional MFC application just work in Windows 8?

Whats wrong with using the MFC Feature Pack[^]? It is available with Visual C++ 2008 Service Pack 1 and beyond and most of the cool stuff works with XP and above.

It amazes me how many people attempt to use redirection instead of acknowledging that someone elses point was valid. At this point in time, the tab above for this forum is titled "Discussions". You were wrong. Just admit it. ;P

Richard MacCutchan wrote:

This forum is not the place for discussions

err, umm "Home Articles Quick Answers Discussions Learning Zones Features Help! The Lounge

If Microsoft keeps insisting that IE 9 will only provide text using ClearType, their share will continue to decline methinks.

Nah. I was just trying to figure out what the Microsoft programmers were attempting to protect against as I hadn't contemplated the scenario that Chuck O'Toole brought up in a different post. He gave me a swift kick in the right direction and I think the mystery is now solved. Thanks for your time.

I had to dig around in MSDN and trace through a few MFC based allocation failures to find out how to change the MFC handler and came across AfxSetNewHandler which does (confirmed this) set the handler for allocation failures in an MFC application. The last time I checked this out (MFC allocation failures) was 7 years back and I only remember walking away with confirming what MSDN says about CMemoryException - "Memory exceptions are thrown automatically by new". Its probably good for one to revisit this topic every so often as I had been concerned that I had been protecting my new incorrectly all this time after seeing the wizard code. Thanks for helping me get to the bottom of this. :)