|
|
|
|
Forum
Please
Log In
to post a new message or reply to an existing one. If you are not registered, please
register.
NOTE: Some forums may be read-only if you are not currently subscribed to
our technical support services.
Subject |
Author |
Date |
|
Mike Van Duzee
|
Feb 27, 2006 - 6:12 AM
|
Our application depends heavily on idle time processing for things such as draws and screen refreshes. Since moving to prof-uis we have noticed that when the mouse is hovering over most of the GUI components (toolbar buttons, controlbar borders when resizing them in MDI app, popup menus in view) we almost never receive any free idle time. CWinApp::OnIdle() almost always return TRUE leaving us no idle processing time. Do you know why this would be happening (does prof-uis control updating scheme post a high number of messages, therefore interrupting any further idle processing)? If so is there anything we can do to get around this?
Thanks
|
|
Technical Support
|
Feb 28, 2006 - 3:28 AM
|
We have received a lot of comments about the idle time processing from Prof-UIS customers. Some of them want the idle processing to be enabled and some not. By default, it is turned off. The following code turns it on: CExtControlBar::g_bEnableOnIdleCalls = true;
CExtGridWnd::g_bEnableOnIdleCalls = true;
CExtPopupBaseWnd::g_bEnableOnIdleCalls = true;
CExtTabWnd::g_bEnableOnIdleCalls = true;
|
|
Mike Van Duzee
|
Mar 1, 2006 - 6:00 AM
|
Setting those flags didn’t really seem to improve our idle time processing, but we’ve been able to reproduce our problem with one of your sample applications. When running ProfStudio it uses 0% of the CPU when it is just sitting there idle. But when you hover the mouse over one of the toolbar buttons, the CPU usage increases to 41% - 56% and it will stay there until the mouse is moved away from the toolbar. We’ve run other sample applications (BitmapEditor, DRAWCLI) that don’t do this. Do you know what could be causing this?
Thanks
|
|
Technical Support
|
Mar 1, 2006 - 12:13 PM
|
We noticed the following: if you comment the ID_TIMER_DELAY_KILL timer processing in the CExtPopupMenuTipWnd::OnTimer() method in the ExtPopupMenuWnd.cpp file, then you cannot not see CPU time eating in the ProfStudio sample at all. This code tracks the mouse movement when a tooltip is visible over a menu item or a toolbar button. In fact, the ::GetCursorPos() Win32 API gets slower in applications with a large number of HWND handles being created. You can alleviate the problem with CPU eating by modifying definitions of the ID_PERIOD_DELAY_KILL and ID_PERIOD_LIFE_STEP preprocessor variables at the beginning of the ExtPopupMenuWnd.cpp file. Both variables should be set to 200.
|
|
Mike Van Duzee
|
Mar 2, 2006 - 7:50 AM
|
That seems to have fixed it. We are still testing, but it looks good.
Thanks a lot for your quick reply.
|
|