"Default implementation filters out WM_PAINT message, redundant WM_MOUSEMOVE messages and system timer message used for caret blinking."

 

That not enough?

I don't have access to our source but as soon as I do I will see if we override the method, inherit from the CJ frame class or implemented our own. Then I'll add the above code to our implementation. Thanks mgampi for what I believe is the solution to the problem. CJ may want to try this in their ribbonsample (which I will also try when I get back to work) and if it solves the problem, add the same solution to their frame window classes.

 

The system is being deluged with a timer that is triggered every 50ms. The timer is not being set when I move onto the command ribbon as long as I am in an unoccupied area. But move the mouse into the "tab" strip (not even over a tab) and the timer is set. Or move the mouse onto any group (don't have to move over a control) and it is set. The timer trips until the WM_MOUSELEAVE message is processed by the ribbon at which point CJ cancels the timer. The timer function being set is CXTPMouseManager::TrackMouseTimerProc and it is being set in CXTPMouseManager::TrackMouseLeave, which is called whenever the menubar base class (commandbar derived class) gets a mouse move (forwarded from the ribbon object).

 

At least that is what is happening in my app.

 

To see if this is what is happening on your system, start the debug version of your app and start spy++. Then use the FindWindow command of spy++ and drag the mouse over the command ribbon and select it. Click the "messages" radio button. Then activate your app and move the mouse over the ribbon so that it moves over the tab area or a group. Then just leave the mouse where it is (to avoid other messages being logged). I quickly see only a steady stream of WM_TIMER messages being reported by spy++ in the messages window.

 

Do NOT have the debugger attached to your app while you are spying on the app as the debugger and spy++ can cause a system deadlock when both attach to a process (not actually a deadlock but it can take forever to get the task manager activated after which you have to kill devenv.exe to get control of the system back).

 

Once you see the WM_TIMER messages in spy++, you will see "tmprc:" followed by a hex address on each WM_TIMER line in the message logging window. This is the address of the timer proc function that is being called. Then shut down spy++ and go back to Visual Studio and attach to your process. Once you are attached, go to the "Breakpoints" window and click the "New" dropdown and choose "Break at function". When the dialog appears, key in the hex address and then move the mouse over the tab or group area. You should start breaking at the function (you will actually break at a "jmp" instruction and then step one time in the disassembly window and you will be at the hex address you set the breakpoint at.

 

You may see the debugger tell you that there is no code for the breakpoint and you can choose the button that lets you see the disassembly window.

 

The timer does not affect the performance of my app since very little processing is occurring in the timer function being called. However any other processes running are affected. But only while your app has focus (timer is cancelled when the app looses focus) and you have the timer running while leaving the mouse over the ribbon window. I am sure customers will notice this and complain. At least ours will as we have had them do so in the past. Some customers have the "As long as I am not doing anything, neither should the app" mentality.