My application has a configuration file and a "Settings" window. When the user confirms the changes in this window they are applied and written to the config file.
These settings are often changed and referenced throughout my program. I'm trying to figure out how to model the accessing and manipulating of these settings. On the one hand, I can't reference the GUI elements directly, that just seems like very bad practice. On the other hand I can't keep reading and writing to the config file because I don't want certain changes to settings to persist, e.g. the current username of the user logged in needs to be stored somewhere; I can't store it in the config file because I don't want the application to "remember" the user having accessed the system.
So is the solution to have a ConfigObj
object, containing all the settings of the program, which is is accessible to all modules of the codebase? Is this a common solution?
But there is a problem which I don't know how to solve, demonstrated in the following scenario:
- Program starts, the
ConfigObj
object is initialised with the config file. - User opens the "Settings" window. The GUI controls are populated with the values from the
ConfigObj
. - One of the values in the "Settings" window is "COM Port", and if the user changes it and clicks "Save Settings" its value will be written to
ConfigObj
as well as the config file. - The user closes the "Settings" window and opens another window "Find USB Port". This window finds an available COM port and assigns it to
ConfigObj.Port
. This change is rather temporary and isn't written to the config file, but now the global-wide selected port for the application is set to this, and other functions depend on this value. - Now the user opens the "Settings" window again: the program should display the current settings of the program, i.e. what's in
ConfigObj
, but how does it know to do this instead of populating from the config file as in Step 1?
I suppose I could compare all values between the config file and ConfigObj
, but is there a more correct way? What's the cleanest way to handle application-wide configuration?
ConfigObj
from config file. Every time "Settings" are opened (2., 5.) thisConfigObj
is read. Changes are saved toConfigObj
(always) and config file (optional). The referenced step in 5 should be 2, not 1, as the program is still running.Configuration
object, is this the common design decision to create a global-access config object?