• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 279
  • Last Modified:

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...
0
jazjef
Asked:
jazjef
1 Solution
 
kbireckiCommented:
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.
0
 
jazjefAuthor Commented:
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?
0
 
HooKooDooKuCommented:
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.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
kbireckiCommented:
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.
0
 
ArkCommented:
Probablu you'r looking for Custom control (containing MSFlexGrid) + PropertyBag?
0
 
jazjefAuthor Commented:
OK.... so, I have now implemented the use of .Writeline and .Readline to store all values for the state of the application to a .txt based file. This seems to work great.... is there any downside to this I am overlooking? Is there an advantage to using the registry over this method and how would the suggested .ini file differ from a .txt based file?
0
 
jazjefAuthor Commented:
My .Readline .Writeline solution is the one that works best for what I want to do.
0
 
kbireckiCommented:
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 http://www.experts-exchange.com/Programming/Languages/Visual_Basic/Q_21596960.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. http://www.experts-exchange.com/Programming/Misc/Q_20732977.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.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now