Forum

hello,

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:

http://www.binaryexperts.com/RFMeasureBetaDemo.exe

Here is the screenshot of my app main window:

best regards,

krompo

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

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.

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

http://www.youtube.com/watch?v=uLDirSi0d3M

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.

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

Please send it to support@prof-uis.com.

hello,

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,

krompo

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.

please find attached my mainframe class:

http://www.binaryexperts.com/MainFrm.h

http://www.binaryexperts.com/MainFrm.cpp

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.

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.

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

http://www.binaryexperts.com/RFMeasureBetaDemo283.exe

krompo

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

http://www.binaryexperts.com/RFMeasureBetaDemo282.exe