Forum

Dear Tech Support,

When I call CExtControlBar::ProfileBarStateLoad to load the previously saved bar state, it fails with the trace message:
Prof-UIS: CExtControlBar::ProfileBarStateLoad() failed to load bar state

I’ve traced the code and it throws an exception when CExtControlBar::InternalDockStateSite::StateSet() calls m_pDockSite->SendMessageToDescendants() at the end of the function.

Do you have any insight on where I should start looking to fix this problem?

Thank you,
-Brett

Please let us know if you changed the number of toolbars and/or control bars when developing your app and if the state loading fails persistently?

Well, I’m porting over an older program to work with Prof-UIS. First I brought over all of the toolbars/control bars without any message handlers. Without the message handlers, the ProfileBarStateLoad function worked correctly.

Then, I brought over all of the message handlers for the toolbars, and that it when the ProfileBarStateLoad stopped working. I guess I can start commenting out message handlers to see which ones are the offending ones?

If you have any popup menus, add a call to UpdateFromMenu for each one of them.

It turns out one of my toolbars is the culprit. I’ve since disabled this toolbar and have gotten the ProfileBarStateLoad to work. Still a mystery as to why this particular toolbar is the problem (resource.h problems?).

Would you send us a light-weight (UI-only) version of your project that demonstrates the problem?

Yes, I will put together a UI-only version of the app to send to you.

We are not sure if you sent the project but we haven’t yet received it.

I have put together the UI shell version of my program to send to you. However, the problem with ProfileBarStateLoad does not show up in this stripped down version. I can still send it to you if you like, but I’m not sure how you’ll be able to track it without the full code.

Your project contains too much code that has to do with U, which makes it difficult to analyze the project quickly. The main problem is that we are unable to start drag-and-dropping any bar nor to open any menu because when the main frame window appears on the screen, after a very short delay the application starts eating 100% CPU time. We have not found any thread hook procedures nor massive timers. Could you prompt us what may cause this in your code?

Only the shell version of the application exhibits this behaviour. I am not sure why it consumes 100% CPU shortly after launch. I’ll track it down and send you a new version. However, the problem with ProfileBarStateLoad does not show up in this stripped down version, so it may not be something you can help with anyways.

The problem I am having with the scrollbar not showing up in the toolbar does reproduce itself in the shell version. Maybe you can look at this, while I track down the 100% CPU bug?

Thanks,
Brett

We believe all these problems can be solved by changing the order of method calls in the CApp::InitInstance() and CMainFrame::OnCreate() methods. You could try initializing the UI completely before initializing any other parts of your application so that you can show the main frame somewhere at the end of CApp::InitInstance().

I have been able to track the slider bar problem down to the customization features in Prof-UIS. If I turn off customization, the slider shows up.

I have sent a new version of my shell UI that does not have the 100% CPU problem and demonstrates this customization problem with the slider.

Could you provide the call-stack that you get at the assertion?

Personally I had ProfileBarStateLoad assertion problem every time I had changed anything in the group of control bars and toolbars or menubars: command identifiers or bars changed, added, removed. Then the settings saved in the registry can’t be applied to the new group of control bars.

From version 2.51 there’s a bEnableThrowExceptions parameter of most ProfileBarState*** functions. Check version history for that. By setting this parameter you can suppress thrown exceptions.

Thank you, I will try the bEnableThrowExceptions flag to see if I can isolate the problem further.