#SetTimer and member func
08-Jul-94 14:44:33
Sb: #30204-#SetTimer and member func
Fm: Andrew Schaub 71224,541
To: Mary Kirtland [MFCJ] 74017,2743
Here's the problem: I want to trap mouse event messages from a given CView and
store them temporarily while I perform my own timing functions to help
segregate single click from double click and a simple up from a simple down. I
then want to fire my own context-specific mouse event messages corresponding to
the events mentioned above. I would rather not derive a new class from CView as
that would require all of our programmers to use my CView-derived class for
mouse processing rather than giving them the option of slipping my routines
into place if/when they need more discrete event firing. Does all this make
sense?
I thought defining a mouse-oriented base class with virtual event functions
would work such that each CView has its own corresponding
mouse-base-class-derived class and a single entry point that gets called by all
the "OnLButton" and "OnRButton" routines to collect and store events that get
timed then redispatched in a more exclusive manner (single click never precedes
double click for example).
This allows each CView to have its own 'special' mouse-processing routines
without deriving anything from the CView itself. This works fine experimentally
except that the timers really hose me because (a) the callback functions cannot
exist as non-static members under each mouse-base-class-derived class, meaning
that I lose context, and (b) any external pointer that temporarily holds the
value of "this" must have a specific type associated with it otherwise the
wrong virtual routines get called.
I could assemble a table of all the virtual functions (or pointers to them) and
index that by some identifier associated with the CView; but that seems awfully
complex and not in the spirit of C++ at all. Am I totally hosed or is their a
way to produce the effect that I want without writing a nested, C-based
mouse-event interpreter?
Should I, as an example, consider grabbing the routines prior to the CView
functions and redefining their behavior with a subclass or hook of some kind?
Thanks,
Andy