Forum

Prof-UIS is quite nice - almost the only thing lacking is good docs for all the classes. But I know how programmers hate to write documentation. :-)

I was just trying to use CExtControlBar::ProfileBarStateSave() as mention on www.codeproject.com. Unfortunately it crashed. :-(

A little bit of tracing through the Prof-UIS code showed that it was causing an assert because in my case CWinApp::m_pszRegistryKey == NULL.

Why does Prof-UIS only save the profile/state information by way of specialized internal functions that only write to the registry? To me, it would make more sense to use CWinApp::WritePrileString() and similar functions becaus ethen PRof-UIS would be saving to or loading from the exact same place that the application will be getting its profile data from. Even if you need to store binary data you could still use ::WritePrivateProfileStruct().

Is there any way to get around this problem and make Prof-UIS save its profile/state data to a specific .ini file?

Dear Cory Albrecht,

Thank you for the good question.

The control bar state serialization is based on MFC’s CArchive class. The CExtControlBar::ProfileBarStateSerialize() method performs both state loading and saving for all the bars inside one frame window. The CArchive object can store any other data besides bar states.

Please take a look at the CExtControlBar::ProfileBarStateLoad() and CExtControlBar::ProfileBarStateSave() methods which are used for bar state serialization with the registry. They are very simple and based on ProfileBarStateSerialize(). Both methods do initialization of temporary CMemFile and CArchive objects and then pass archive to ProfileBarStateSerialize(). You can easily write your own BarStateLoad() and BarStateSave() methods to store control bar state anywhere and I can help you with this task :-)
(my e-mail still l_sergiy@fossware.com)

Why the state serialization is CArchive-based?
1) The structure of control bar data is tree-like and contains dynamic number of nodes depending on mutual bar positions. It is convenient to use binary CArchive stream to store this data.
2) CArchive can be based on any kind of CFile (memory, shared memory, file on disk). Please take a look at the StateInFile sample. It shows how to load/save bar state in file on disk.

Why (CWinApp::m_pszRegistryKey == NULL) assertion happened?
I think you forgot to initialize this string. In CYOURApp::InitInstance() just add one line of code:
SetRegistryKey( _T("YourCompanyNameIsHere") );

Is there any way to get around this problem and make Prof-UIS save its profile/state data to a specific .ini file?

It is possible, but you need to code a function(s) which will move binary data from CArchve to multiply lines in the INI file (and vise versa). You can use CExtCmdManager::FileObjToRegistry() and CExtCmdManager::FileObjFromRegistry() methods as a sample.

Best regards,
Sergiy Lavrynenko.

>Why (CWinApp::m_pszRegistryKey == NULL) assertion happened?
>I think you forgot to initialize this string. In CYOURApp::InitInstance() just add one line of code:
> SetRegistryKey( _T("YourCompanyNameIsHere") );

No, it wasn’t because I forgot to initialize it.

In this specific app which I am using to test Prof-UIS with, it can get its settings either from the registry or from a .ini file explicitly named on the command line.

In fact, I write this type of functionality into all my programmes because has experience has taught me that the registry simply isn’t the best place for storing settings in every case. Whether it is the average user who wants to transfer their settings for the programme to another computer (they aren’t going to know how to use regedit to export and import keys) or it is a public machine where multiple people use a single login to run a specific programme but still need to store individual settings (a common case in small businesses, non-profits, charities, or church-based organisations which often don’t hav ethe money to buy multiple copies of expensive programmes), this is actually a common occurrence. Far more common that Microsoft realized *(and perhaps mor ethan they are willing to admit) when they developed the system registry idea and started calling ::WriteProfileInt()/::WriteProfileString() and related functions "obsolete". A great many programmes are still written today to specifically use .ini files instead of the registry because of needs like this.

IMHO, writing Prof-UIS to be registry-specific in this manner instead of going through the CWinApp profile functions was bad decision. It makes Prof-UIS less flexible and forces the devloper to unecessarily write code to work around it.

Hi,
Thank you for the explanation.
I will think about INI files.
Regards, Sergiy.