Forum

CExtControlBar::ProfileBarStateLoad is failed in its call to ProfileBarStateSerialize. I’ve seen this happen a couple of times before, each time when my app design introduces a new CExtControlBar or removes one from the design. (I’m talking here about the app design, not showing/hiding CExtControlBars at run-time.)

I’ve been able to work-around this problem by using RegEdit to delete the entire tree of HKEY_CURRENT_USER\Software\MyApp\ProfUIS254. That highly confirms my suspicion that the problem is that ProfileBarStateSerialize cannot deal with changes in the app’s list of CExtControlBars.

One solution for my end-user is that my setup program could delete the registry HKEY_CURRENT_USER\Software\MyApp\ProfUIS254 entries if a new version of my app changes the list of CExtControlBars it uses. But I don’t believe this is a very reliable solution.

The solution I have in mind is this: My app will call CExtControlBar::ProfileBarStateLoad inside a try/catch. If the call fails (throws an exception), then my app will programmatically remove the registry entries for HKEY_CURRENT_USER\Software\MyApp\ProfUIS254.

Is there a better solution already built into Prof-UIS?

Cheers
-- Mark

The code for serializing control bars requires all the control bars described in the saved data to be instantiated (exist) in the frame window. If that’s not the case, the ui state assumes to be loaded unsuccessfully. We are working on a new version/bar independent algorithm which is based on tree-like named nodes compatible with XML serialization.

That’s a good that a future version of Prof-UIS will handle changes in the list of control bars. In the mean time, I’ll implement the work-around I proposed above, to do the ProfileBarStateLoad in a try/catch, and if an exception is thrown, then clear the ProfUIS registry entry for the app controls.

Cheers
-- Mark