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?
That is a fairly basic logic/counting problem that you should be able to figure out by writing the numbers on paper, and deciding how to calculate the number of digits vs the number of spaces for each value.
Your loop values are slightly off. You should be counting 1 - 3 - 5 - 3 - 1, and printing the numeric values in each line rather than stars. Your main loops should be something like:
int num = 5;
// go from 1 to 5
for (index = 1; index <= num; index += 2)
// print the first set of values
printf("%d\n", index); // just to show the number
// already printed the 5 set, so go from 3 to 1
for (index = num - 2; index >0; index -= 2)
// print the last set of values
That is an example, your job is to fill in the fine detail. You will learn much more by trying it yourself than if someone else writes it for you. As an exercise you can try different values of num also.
I've had a quick look, and IMHO the code is severely lacking. Most importantly, the classes are often passed by value instead of by reference. Therefore, every time a hard copy is created. Apart from potential issues regarding performance and memory for more complex object instances, this also means that any code attempting to modify an object using these calls will not work!
Example: the destructor code passes the object that is to be destructed by value!? This will allow you to clean up resources such as pointers to allocated secondary objects, but if you're managing something more complex, such as a database connection or file handle, you're going to have severe issues, if you can properly clean this up at all!
Similarly, the sound() functions create local hard copies of the object that in this case is correctly being passed by reference. Why the author did this is beyond me - it generates needless overhead and ensures that you can not modify the original object. Most importantly, modifying the local copy will not change the behavior of the referenced object that was passed to the function, i. e. the effect of these functions is zero!
Also the example main function doesn't show inheritance at all, because it always directly calls the sound() function on the class interface it is created as (e. g. calling dog.sound()). The only way to prove there is something like virtual inheritance at play is to store the cat and dog objects as animal references, and call the sound() function via the animal class interface. Without actually trying, I predict however, it won't work, because the "derived" sound() functions won't be called, and, therefore, the super class won't adjust it's behaviour.
Always referencing class objects through pointers would go a long way to fix the code and get it towards what the author originally intended. But that still wouldn't introduce polymorphism or encapsulation.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Last Visit: 31-Dec-99 18:00 Last Update: 23-Sep-23 3:45