TabClientWnd using lots of CPU

I got a few complaints from some users of my software saying that on their Dual XEON dev machines, my product was using 15-20% of the CPU in total (across 4 processors) when they werent doing anything at all.

This figure went down slightly if they had only 1 doc open but went up significantly with lots of documents.

After some testing, we found that if they turned off the client tabs option so they just had maximised child windows for each document it went down to 0%.

It seems that the MDITabClientWnd is using a lot of CPU, have you noticed anything in this area and/or done any profiling on it?

Hi,

Another thing to consider is CWinApp::IsIdleMessage - if you override this you can greatly reduce idle processing.

What is this override used for then and what did you do, just return FALSE?

mgampi wrote: Hi Dan;   This virtual function determines whether a message in the message queue is a message good for idle processing or not. If this function returns TRUE, the OnIdleUpdate... processing is done (OnUpdateCommandUI() handlers are called). In the default implementation WM_TIMER messages are defined as 'idle' messages, resulting in OnUpdateCommandUI() calls. In my application, each mdi child window has started its own timer and the timer interval is about 200ms. This means that after opening one window, the OnUpdateCommandUI() handlers are called 5 times per second. 10 open child frame windows lead to 50 calls to all OnUpdateCommandUI(). This uses lots of CPU!!!   So I wrote my own IsIdleMessage() to return also FALSE when WM_TIMER messages are handled.

I had to ignore most of my registered messages. I have quite a few common controls in the toolbars and updating these is / was quite expensive.