tags:

views:

47

answers:

1

By default, a basic MFC C++ project in Visual Studio 2010 will store all its workspace settings in the HKCU registry hive under a user-configurable key name. This includes last window size/position, ribbon settings, status bar, etc.

How can you disable this feature completely so as to not write to the registry at all?

I tried not setting SetRegistryKey(), which gave me a debug assertion from the framework on first read/write to registry. SetRegistryKey((LPCTSTR)NULL) gave the same results. SetRegistryBase() seems to have no effect. No other methods in CWinApp/CWinAppEx seem to help.

+2  A: 

Edit: My original answer was wrong. I have edited the answer.


You can tell MFC to store settings in an .ini file instead of the registry. See this previous answer. (Update: That only works if you are not using CWinAppEx.)

If you want to prevent MFC from saving some of the state of the menus and toolbars altogether, add the following to your app’s constructor:

m_bSaveState = FALSE;

The m_bSaveState member is only defined if your app is derived from CWinAppEx.

Alternatively, you can override CWinAppEx::SaveState and CWinAppEx::LoadState.


To eliminate the WindowPlacement registry key, override CWinAppEx::StoreWindowPlacement.

You may still get other registry entries being written. A complete solution would involve subclassing CSettingsStore and then, in your application, calling CSettingsStoreSP::SetRuntimeClass. (See this for more information.) This is fairly difficult because there are a whole bunch of virtual functions you will have to override in your custom CSettingsStore class.

Nate
This partially worked. Setting to `FALSE` disabled a number of reg keys, but a couple still remained. Overriding `SaveState()`/`LoadState()` to do nothing reduced it down to just "WindowPosition" being saved. The answer in the referenced question didn't work. Got an assertion from omitting call to `SetRegistryKey()` and even if not, the .ini file was not created. Might be a VS2010 difference?
spoulson
Yikes. I was testing with a `CWinApp`-derived class, not `CWinAppEx`. Thanks for the heads-up. I updated the answer to show how you can get rid of `WindowPlacement`. (Is that what you meant when you said “WindowPosition”?)
Nate