Forum

Although it works fine on most machines, on some of our clients’ machines we have a property sheet that takes about a minute to draw!

When the dialog is opened, the first page of the property sheet appears and appears very fast.  However when switching to any of the other tabs, the new page loads incredibly slowly.  We can see every individual control appearing one at a time, with maybe a second between each one.  Every label, every edit box, one by one.  On most machines the whole page comes up instantly, but on others it does this slow appearance making it more or less unusable.

Our dialog is being created by a DLL the links to our main app, and we actually get the same problem whether we use MFC or ProfUIS controls and property pages/sheets, but we didn’t have the problem before using ProfUIS, and I still suspect it is related to ProfUIS.  My guess is that the controls on the first page are created before the window is realised, which is fast, but the window is already visible by the time the second page is created, and maybe extra windowing messages are causing excessive repaints as each item is added, or something like that.  The controls are added from a resource by the way, not directly from our code.

Have you heard of anything like this before?  Any thoughts on what could cause it or how to fix it?

Thanks,

Rob.

The property page window becomes created when you activate it for the first time. They are created internally by the Windows Property Sheet control and then subclassed by MFC objects. So, you can fully lock the property page window updating via handling the WM_INITDIALOG message:

ON_MESSAGE( WM_INITDIALOG, HandleInitDialog )

LRESULT CYourPropertyPage::HandleInitDialog( WPARAM, LPARAM )
{
            ::LockWindowUpdate( m_hWnd );
LRESULT lResult = CExtResizablePropertyPage::HandleInitDialog( 0, 0 );
            ::LockWindowUpdate( NULL );
            return lResult;
}

If the slow effect occurs on first displaying of the property page window, then you can try to do the same with the WM_SHOWWINDOW message:

ON_WM_SHOWWINDOW()

void CYourPropertyPage:: OnShowWindow( BOOL bShow, UINT nStatus )
{
            ::LockWindowUpdate( m_hWnd );
            CExtResizablePropertyPage::OnShowWindow( bShow, nStatus );
            ::LockWindowUpdate( NULL );
}

We think you should try the following:

1) Run the property sheet based app on a slow machine. Let it display its first tab page.

2) Run the SPY ++ tool on the same machine, spy all the messages of all the windows of all the threads in your app.

3) Select some slow tab page in your app. Take a look at the messages displayed in the SPY++ tool.

You can repeat the same test on fast machine. If the message loop is overloaded on a slow machine, then there is some hook based software is installed on it or some other reason is present. If the message loop is equally overloaded on both machines, then there must be something else like heavy idle time processing, a slow network problem, a slow printer detection, anything else related to specific settings and environment of a slow machine and set of APIs used in your APP.

Unfortunately we don’t have a machine that can reproduce it, and our client is in another country.  They have two very different machines where this happens though (one new with up-to-date specs, and one 5 years old).

I was thinking of using LockWindowUpdate() and UnlockWindowUpdate() around the code which populates the slow pages.  I wonder if the first page, which is fast, is populated before the window is made visible, whereas the other pages might be populated while visible, and this may somehow slow it down.  However, I don’t know where to lock the updates.  The pages are populated via a dialog resource template, not in our code.  It seems by OnInitDialog() the page is already populated.  I tried overriding all versions of the virtual Create() and CreateIndirect() methods for the page, but neither are ever called.  Do you have any clues as to where I could put my lock calls?

Thanks,

Rob.