CompuServe Messages

#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