Idea to create json file with defaults settings, what will be automatically loaded into new local settings db at creating process.
Group 'default' means its comes from json file and if user change it later - we will have user id there, that allow us to have different settings for different users but at same time keeping "original" ones in case user decide to reset.
What one of the basic steps of transition all settings into local db. Once application is running - will be possible to import already existing settings into local db, as well as switch where to have save them: to windows registery or to local db.
Settings file also could be encrypted, and file will be locked on current machine, that allow all users to use it, but not allow to transfer it to another machine. (If they do it will not work)
mR don't use any hard-coded passwords for such, only hdd id + machine name (what is hashed by SHA256) so couldn't be traceable from memory dump. Later will be possible to lock by user with own password, but that will required to enter on every start as mR will not save it.
- Added new registry settings for managing security-related configurations on the Security Page.
- Implemented an encryption key generator to securely generate a password for store in the registry.
- Passwords are placed encrypted on the clipboard for 30 seconds.
- Update documents and finalize comments
- Added registry settings for the Connection Page.
- Added registry settings for the SQL Serverl Page.
- All settings implemented with async registry logic
- Comment unused settings for Connection Page
- Update documents
- Added registry settings for the Tabs and Panel Page.
- All settings implemented with async registry logic
- Comment unused settings
- Update documents
- Added registry settings for the Notification Page.
- Added registry settings for the Appearance Page.
- Added registry settings for the Startup and Exit Page.
- All settings implemented with async registry logic
- Moved async registry loading logic to OptRegistryCredentialsPage and OptRegistryUpdatesPage to improve structure and maintainability.
- Removed obsolete logic and redundant code that is no longer needed due to the new asynchronous architecture.
- Enhanced settings management to take advantage of the just-in-time loading mechanism.
- Improved performance by ensuring registry settings are loaded asynchronously right before they are needed by the UI or application logic, minimizing unnecessary loads.
- Update documents
- Added the RegistryLoader class to handle loading of registry settings.
- Implemented Lazy<T> for singleton pattern to ensure only one instance of RegistryLoader is created.
- Added support for asynchronous loading of registry settings to improve performance in async workflows.
- Designed the class with thread safety in mind, leveraging ConcurrentDictionary for storage.
- Included logging of debug messages to track the load process and timing.
This commit finalizes the Update Options Page with the following changes:
- Removed unnecessary methods due to new features of the registry handler class.
- Updated and added comments to improve code readability and understanding.
- Implemented UI optimizations such as disabling the frequency control and showing "Never" in the combobox.
- Enabled the password storing ability, making it functional but not yet usable.
- Applied some code optimizations for improved efficiency.
This commit finalizes the Credentials Options Page with the following changes:
- Updated and added comments to improve code readability and understanding.
- Enabled the password storing ability, making it functional but not yet usable.
- Applied some code optimizations for improved efficiency.
This commit refactors the registry settings interaction classes by consolidating the multiple entry classes for int, string, bool, etc., into a single class that supports multiple data types. This change simplifies the code and enhances readability.
- Consolidate multiple entry classes (int, string, bool, etc.) into a single class
- Introduce WindowsRegistryEntry<T> to support multiple data types
- Fixed a bug that occurred when trying to open the log file on the Notification settings page.
- Removed unnecessary file association when user tries to open the log file on the Notification page. The "choose file" dialog handles the extension as it is fixed on .log
- Implemented fallback to open file explorer to the specified file location if mRem fails to open the log file.
correct build number calculations - now its days from last release + hour + minute of build
some changes to migrate to json schema + preparation of using db to save settings
