Professional UI Solutions
Site Map   /  Register


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.

Forums » Prof-UIS General Discussion » freezing problem after upgrading to 283 from 282 Collapse All
Subject Author Date
Andrej Kasa Jun 11, 2008 - 4:51 AM


I just upgraded to 283 from 282 without changing anything in my code - just rebuilded with ProfUIS283sn.lib, nothing else.

After that following behaviour is occuring every time after the app is started and main window is displayed: For about 3 seconds after the displaying of the main window a windows hourglass (waiting) cursor is displayed and application is frozen. after the 3 seconds app resumes and the hourglass return to normal state (arrow). This problem occurs only for these themes: LunaBlue, Obsidian, CExtPaintManagerOffice2007_R1. I am running Windows XP SP2 on Core 2 Duo machine.

Can you please let me know why is this freezing happening and how to overcome it? Again, I did not do any changes to my code and on version 282 this problem never occured.

To test it, you could download my app from here:

Here is the screenshot of my app main window:

best regards,


Andrej Kasa Jun 13, 2008 - 5:04 AM

have you tried to test it on Winwows XP? Because on Windows Vista this problem is not occuring.

Technical Support Jun 13, 2008 - 4:54 AM

Both versions of your application are starting up without any delay on our computers. So we need more details about your computer. It would be also helpful to take a look at the source code of the application and the main frame classes.

The slow startup was a known problem in v.2.82 and we changed timer based code and command updating routes in v.2.83 in order to fix this problem. At least we made all the sample applications starting quickly.

Andrej Kasa Jun 13, 2008 - 9:14 AM

I have made a short youtube video that demostrates the problem:


Technical Support Jun 14, 2008 - 3:36 AM

This video simply describes the problem better than any text description in forums and e-mails. But it does not allow us to guess what’s wrong in your project or in Prof-UIS itself. We need to be able to reproduce this problem using either a Prof-UIS sample application or a your own test project.

Andrej Kasa Jun 14, 2008 - 10:47 AM

could you provide me with the email where I can send you my app sources?


Technical Support Jun 14, 2008 - 3:28 PM

Please send it to

Andrej Kasa Jun 14, 2008 - 3:55 PM


it seems though I have found a way to solve my problem in the meantime. In my app I called g_PaintManager.InstallPaintManager(RUNTIME_CLASS(CExtPaintManagerOffice2007_R1)) from within one of my views (specifically the list view in the bottom right side of my app -> CUnitListView::OnInitialUpdate()). After I moved this call to CMainFrame::PreCreateWindow no more problematic behaviour was observed. Do you think the PreCreateWindow of the mainframe is a good place to perform the mentioned call?

Thank you for your assistance and help!

best regards,



Technical Support Jun 16, 2008 - 2:05 PM

Many Prof-UIS classes have the CExtPmBridge class as a second parent class. All the CExtPmBridge-derived classes in Prof-UIS are subscribed to paint manager changing event. So, when you select a new global paint manage, then all the CExtPmBridge-derived objects are notified about this. This mechanism allows Prof-UIS controls to re-paint themselves automatically and/or re-scan required metrics like margins, paddings and part sizes after paint manager changing or any desktop setting changing. So, it’s much more efficient to setup a required paint manager before any objects of based on Prof-UIS classes are instantiated and created in the memory. The CMainFrame::PreCreateWindow() method is invoked before any windows inside main frame window are created. So, selecting paint manager in it is OK. But we prefer to select it even earlier: in the InitInstance() virtual method of the CWinApp-derived class before main frame or dialog window is created or in the constructor of main frame or dialog class.

Andrej Kasa Jun 13, 2008 - 5:27 AM

please find attached my mainframe class:

Please when testing start the application several times, since first time after installing this problem is not present. I tried it on XP on 2 different machines and the problem was the same. I assume that the problem is somewhere in the main frame window non client area, since it occurs only on themes with not default title bar (like in luna blue, obsidian, etc.) when using default xp look this problem never occurs. Since in case of Win Vista Windows Aero takes care of the titlebar and rest of nc area, therefore is probably not occuring as well.


Technical Support Jun 14, 2008 - 3:18 AM

We tested our applications on Windows XP with SP2 and SP3. The initialization delay can be seen when you run a large application like ProfUIS_Controls, ProfStudio or RibbonBar. The sample applications like DRAWCLI always start immediately. Could you try to comment out everything possible in your CMainFrame::OnCreateClient() method and run your application. There must be something heavy created there.

Andrej Kasa Jun 11, 2008 - 6:01 AM

here is the link to the 283 version so you can see how it should behave (no delay at all):



Andrej Kasa Jun 11, 2008 - 6:04 AM

sorry, my mistake. it should be 282 of course: