I have a MFC application created by the MFC Project Wizard. I wanted to save/read application settings in the registry and so asked this question to find a C++ Registry wrapper as the Windows API is very messy. However, I have now heard that the MFC provides a way to do this. Is this true? If so, how can I read/write values, see whether a key exists and get a list of all the keys?
MFC provides an easy way to read/write Windows registry.
In your project you'll have a global CMyProjectName theApp; object.
CMyProjectName inherits CWinApp class which provides the SetRegistryKey() method.
That method sets theApp to write in the registry instead of an "ini" file.
In the documentation check out
CWinApp::GetProfileInt
CWinApp::GetProfileString
CWinApp::WriteProfileInt
CWinApp::WriteProfileString
methods on how to read and write integers and strings in the registry.
Related
So I'm just learning MFC to see if I want to start using it over normal Win32 programming. I have a SDI MFC application setup. I have a view with members that create a CTreeCtrl and CHeaderCtrl. I have a CDwordArray setup as m_ColWidths that is currently in my View class, but using MFC, should this be in the document class instead since I'll want to save and restore it to keep the users widths when program exits? I guess even though it's only part of the view it's still data and use GetDocument() to reference them?
TIA!!
Application state should not be stored in the document. The purpose of the CDocument(-derived) class is:
A document represents the unit of data that the user typically opens with the File Open command and saves with the File Save command.
CDocument supports standard operations such as creating a document, loading it, and saving it. The framework manipulates documents using the interface defined by CDocument.
The designated entity to store application state (e.g. size and visibility of UI elements) is the CWinAppEx(-derived) implementation:
CWinAppEx handles the application state, saves the state to the registry, loads the state from the registry, [...].
I understand there are functions that can easily write windows registry, however I found out that in new MFC project created with wizard, some information (like split bar position, visibility of controls) gets stored automatically (or at least I found no CWinApp::Write* calls in the project). Since I have also older projects that don't have this behaviour I need to figure out how to make this without help of project wizard. Would anyone please know how does this work?
The MFC control state saving magic happens in the 'New' MFC Feature Pack, specifically in the SaveState methods, for example CMFCToolBar::SaveState.
To take advantage of this you'll therefore need to upgrade your Toolbars and Menus to use the newer controls and upgrade your application to inherit from CWinAppEx. I recommend that you use a New MFC Wizard based app as a guide on how to upgrade your old MFC app.
Most of the information is saved in CPane::SaveState(), thus if you want state of some component saved, you need to use classes derived from CPane. (for more info here is the class hierarchy).
The process of saving window states is initiated through CFrameImpl::OnClosingMainFrame(). This function in turn calls CWinAppEx::SaveState() which saves some application settings and then ALL instances of CMFCToolBar (they add themselves to global list of CMFCToolBars in call to OnCreate). In a similar way all dockable panes are saved but the list belongs to your main frame. Then positioin and size of your main frame is saved.
CViews and CFrameWnds are somewhat less favored, for what I found and tried out, the only information saved was visibility.
I used that loooong time ago. If I correctly reminds it, you should save the informations you want in a overridden CWinApp::ExitInstance() before calling base class method, and you load them in CWinApp::InitInstance. Be sure to allow for default values, because at first run, there will be nothing to load, and do not forget to call (or copy) base class.
I have created a custom toolbar for IE. I am placing my COM DLL in System32 folder. IE is able to load my toolbar in protected mode. My toolbar should read some data from ini file which is created in InternetCache folder. I am not registering my COM component to any category (e.g. CATID_AppContainerCompatible).
My question is
1) Is it compulsory to place the my DLL in sub folder of program files?
2) Do I need to register to app container category?
3) How can I make sure that my toolbar is compatible with protected mode.
Thanks in advance.
Regards,
Santhosh
I used to develop a BHO for IE6+ before and hope you'll find those answers useful.
1) Is it compulsory to place the my DLL in sub folder of program files?
Don't remember exactly but if it's both signed and placed under a trusted location the more chances IE will pick it up.
2) Do I need to register to app container category?
Just registering a COM DLL module should be enough.
3) How can I make sure that my toolbar is compatible with protected mode.
It is by default but in protected mode you'll receive 'access denied' error on attempts of reading from or writing to many locations both on file system and in registry.
In registry you can use HKEY_CURRENT_USER\Software\AppDataLow and %USERPROFILE%\AppData\LocalLow on file system.
I have an older MFC project build in VS 2003 that I want to port to VS 2010. The project uses an ActiveX control for grids, namely, VSFlexGrid7 from Component One. The problem is, that this version of the ActiveX control does not work in Windows 7 (which is what I have). There is a newer version of the grid, namely, VSFlexGrid8 which should be compatible with Windows 7.
The solution would be to replace all the older controls with the newer ones.
My question is, what would be the steps in replacing the controls, without touching other parts of the project. What is the simplest method to accomplish this? Do I have to modify classes, resource IDs, etc.?
[Solution: Replace CLSIDs in the .RC file]
The ActiveX control is bound to the resource file via the guid that represents the control. If you were to look inside the .rc file you will see the control with the associated guid. In your case, it's probably best to completely remove the control from the dialog (using the resource editor) assuming that you can drag the newer version onto the same dialog. Once you've done that, you'll need to generate a new class wrapper for the control. The class wizard should be able to handle that for you. Once you've got a new class wrapper that represents the control, you'll need to replace the prior wrapper class in your source code.
Usually the control is created somewhere in your dialog code with CreateInstance.
If the interface is compatible (I assume it is) , you just have to change the name or GUID that is used in the CreateInstance Code.
I am working on a windows application that has a shockwave flash player embedded in it.The C++ part should be able to call Flash movie methods and vice versa.Initial experiment was done using MFC.It works.But now I want to port it to Qt as it allows easier UI development.Qt has got QAxObject which holds the ActiveX control you assign to it via setCotrol() method which should get a classID of the ActiveX or its name.Because the classID is more reliable than a name and because I have not found an example where flash player ActiveX is accessed using a name ,now I want to know how to retrieve that classID from the system registry of the OS.I suppose that for every machine some specific activeX classID may vary (correct me if I am wrong on it) .If it is true then I need to access the registry ,find shockwave activeX classid and then pass it into QaxObject::setControl() method.How do I do that?
Forgot to mention that in MFC application the ActiveX control gets the requested ActiveX automatically once you select the ActiveX type from the list of available system controls.In Qt you have no such an option.
Reading this http://www.nirsoft.net/utils/acm.html I understand that the CLASSID is constant on any machine.Is it true ? If yes then please discard my question as there is no reason searching for the ActiveX key on specific machine by the ProgID if it is the same always.
Thanks.
It would be better to query from the registry by mime type. You can find details on where that is stored here:
http://msdn.microsoft.com/en-us/library/aa751976%28v=vs.85%29.aspx
You can look up the mimetype in the registry and get the CLSID from that. You can look it up by name as well; the locations of both registry keys are explained in that document.