jazjef
asked on
How do I save the settings, data objects, and the overall state of a VB6 program interface?
How can I save the current state of my VB6 program interface including all the objects and their data values, control settings etc? Is this done via an .ini file or in the registry? Does one have to specify each object or is there a 'blanket' way to save all objects and states? Many thanks...
kbirecki
Vb6 does not have a built in way of "saving state". You have to do it yourself. But you can use ini files or registry settings depending on how you want to manage the app. Keep in mind whether you want global settings for a given workstation or per user (or possibly both). Unless you want to do a lot of work to manage an ini file to handle multiple user scenarios, using the registry is a better way to go for flexibility. Ini files are good for quick and dirty storage of settings, but using either option is very easy code-wise.
ASKER
Well, I have a couple of MSFlexGrid objects on one of the forms. It's a baseball application and each flexgrid would have a roster of about 35 players and 20 columns of data. Is it practical to store this data in the registry or should I consider just writing to a file and loading it all back in?
I'm surprised there's nothing that has been developed that will inventory all program controls, their settings and data state, and then generate some type of database/file that would save/load them back in. Is it not possible to develop something like this as a control add-on and sell it commercially?
I'm surprised there's nothing that has been developed that will inventory all program controls, their settings and data state, and then generate some type of database/file that would save/load them back in. Is it not possible to develop something like this as a control add-on and sell it commercially?
The typical arrangment is that the "data" you work with (the players and their statistics) are stored in a data file, while "data" about the state of the application get stored in the registry or an INI so that you can reuse the same screen layout for different data files. Plus, that way you don't have to update the data file just because the screen layout has changed.
However, if you only will ever have one data file, then it wouldn't be unreasonable to store ALL the information in a single file that gets updated when ever the application is running.
However, if you only will ever have one data file, then it wouldn't be unreasonable to store ALL the information in a single file that gets updated when ever the application is running.
Another thought I had was to consider whether the app runs on multiple workstations or if users roam and you want the settings to follow the user. In that case, saving to the registry is nit helpful. You'd want to save settings in an ini file on the server per user and each user logging on to the app would be connected to their own ini settings.
Probablu you'r looking for Custom control (containing MSFlexGrid) + PropertyBag?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
My .Readline .Writeline solution is the one that works best for what I want to do.
Glad you solved your problem. Sorry, I didn't answer your question, I had a "health intermission" at the local hospital. Ini files are text files, so they are essentially one in the same. It's just a matter of how you handle them. INI's have a common understood pattern, but you can store your settings in any format that is convenient. The convenience of INI files is that there are routines that make the use of INI files much easier (i.e. one line statements that read or write ini files, such as what is discussed in https://www.experts-exchange.com/questions/21596960/Read-Write-From-INI-File-in-VB6.html). This way you don't have to manage the whole process of reading in and writing out the whole file. It's kind of like a simplified text-file database - just read/write what you want and the rest remains the same.
As far as disadvantages/advantages of various approaches, just the things I mentioned in a previous post. Think about where and how the settings are to be used. Are they user-specific, workstation-specific, do they need to be global across a network or not, do they need to be functional on disconnected systems?
Settings stored in a commonly accessible text file (INI or otherwise) are convenient, portable and can easily be used globally (i.e. users can access it from a common shared drive, and if you have to make changes you make them once in a commonly shared text file instead of on each workstation.) The potential downside is that text file-based storage of settings can potentially experience corruption, user-tampering, and is generally considered "old world". However, many of my apps use them because we utilize standard setups for all users and try to keep them consistent. Some companies like to let users customize to their heart's content, so they use locally stored files per workstation or local registry settings. The downside of this approach is that when a user goes to another workstation, their settings are on the other computer and they have to be setup again.
Settings stored in the registry are a common method, for which there are also simplified methods (i.e. https://www.experts-exchange.com/questions/20732977/VB6-Registry.html). The registry is actually a database and has certain advantages as a database (shared settings across applications, etc.), and it has per-user designated areas (HKCU) and per-workstation areas (HKLM). But it is not portable beyond the individual workstation.
Another option is to store settings in your own database (such as an Access MDB file), which, if needed, could be a common repository for any given user no matter where they log in, or replicated from a common server-side db. The downside of this is when they don't have access to the network, such as a disconnected laptop, they have to have their own copy.
So where you store your settings is dependent on the needs of the app, and how you store them is dependent on how you want to use them.
As far as disadvantages/advantages of various approaches, just the things I mentioned in a previous post. Think about where and how the settings are to be used. Are they user-specific, workstation-specific, do they need to be global across a network or not, do they need to be functional on disconnected systems?
Settings stored in a commonly accessible text file (INI or otherwise) are convenient, portable and can easily be used globally (i.e. users can access it from a common shared drive, and if you have to make changes you make them once in a commonly shared text file instead of on each workstation.) The potential downside is that text file-based storage of settings can potentially experience corruption, user-tampering, and is generally considered "old world". However, many of my apps use them because we utilize standard setups for all users and try to keep them consistent. Some companies like to let users customize to their heart's content, so they use locally stored files per workstation or local registry settings. The downside of this approach is that when a user goes to another workstation, their settings are on the other computer and they have to be setup again.
Settings stored in the registry are a common method, for which there are also simplified methods (i.e. https://www.experts-exchange.com/questions/20732977/VB6-Registry.html). The registry is actually a database and has certain advantages as a database (shared settings across applications, etc.), and it has per-user designated areas (HKCU) and per-workstation areas (HKLM). But it is not portable beyond the individual workstation.
Another option is to store settings in your own database (such as an Access MDB file), which, if needed, could be a common repository for any given user no matter where they log in, or replicated from a common server-side db. The downside of this is when they don't have access to the network, such as a disconnected laptop, they have to have their own copy.
So where you store your settings is dependent on the needs of the app, and how you store them is dependent on how you want to use them.