I prefer not to clutter up my registry with data that is only of temporary utility, but to use an .ini file with the same path as the application to hold the app's parameters, MRU file names, serialized data, etc. I.e, to have an application-specific registry. Some may view this as heresy, insofar as Microsoft went to great lengths to combine all its .ini files into the registry and requires developers to adhere to that method of archiving every app's data, wanted or not. The registry is far to fragile to try to clean up, so I prefer to stay clear of it as much as I can.
I can almost do the MRU tasks I want with Win32++, but (apparently) there is no way to set the m_nMaxMRU value except by using the LoadRegistryMRUSettings() CFrame method. Would it be (or is it) possible to set this value without engaging the registry?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the more modern operating systems, using the registry is the preferred way of storing application settings. On Vista and above, your application would need to be run as administrator if the application was to write to files located in places like "C:\Program Files". That might not be an issue for you, but might be an issue for anyone else you give your application to.
If you choose to save settings in an ini file, you could override LoadRegistryMRUSettings in CMainFrame to load these values from your ini file. Your CMainFrame could also have its own m_nMaxMRU (or similar) member variable.
Best regards,
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am stuck on an old XP machine that I need to keep running until I can translate some MFC apps written using Visual Studio 6.0 into 64 bit form suitable for my Windows 8.1 machine. So far, I have translated MFC CArchive, CTime, and CDataExchange for my use. It is slow, but I've got time--I'm retired. I wasn't aware of the restrictions you mention, and I expect there will be a lot of surprises when I do make the changeover. Thanks, as always, for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like your CArchive, CTime and CDataExchange added to Win32++, you are most welcome to send them to me. You will find my direct e-mail address on any of the header files in the Win32++'s include directory.
Best regards,
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I prefer not to clutter up my registry with data that is only of temporary utility, but to use an .ini file with the same path as the application to hold the app's parameters, MRU file names, serialized data, etc. I.e, to have an application-specific registry. Some may view this as heresy, insofar as Microsoft went to great lengths to combine all its .ini files into the registry and requires developers to adhere to that method of archiving every app's data, wanted or not. The registry is far to fragile to try to clean up, so I prefer to stay clear of it as much as I can.
I can almost do the MRU tasks I want with Win32++, but (apparently) there is no way to set the m_nMaxMRU value except by using the LoadRegistryMRUSettings() CFrame method. Would it be (or is it) possible to set this value without engaging the registry?
Hi Robert,
On the more modern operating systems, using the registry is the preferred way of storing application settings. On Vista and above, your application would need to be run as administrator if the application was to write to files located in places like "C:\Program Files". That might not be an issue for you, but might be an issue for anyone else you give your application to.
If you choose to save settings in an ini file, you could override LoadRegistryMRUSettings in CMainFrame to load these values from your ini file. Your CMainFrame could also have its own m_nMaxMRU (or similar) member variable.
Best regards,
David
I am stuck on an old XP machine that I need to keep running until I can translate some MFC apps written using Visual Studio 6.0 into 64 bit form suitable for my Windows 8.1 machine. So far, I have translated MFC CArchive, CTime, and CDataExchange for my use. It is slow, but I've got time--I'm retired. I wasn't aware of the restrictions you mention, and I expect there will be a lot of surprises when I do make the changeover. Thanks, as always, for your help.
Hi Robert,
If you would like your CArchive, CTime and CDataExchange added to Win32++, you are most welcome to send them to me. You will find my direct e-mail address on any of the header files in the Win32++'s include directory.
Best regards,
David