Tips on storing user data

[Alan vanBiervliet]

Another basic question from a newbie. Yes i understand that it is real easy to store and retrieve data from registry keys in AMS 5. However, for compatibility across OS and for "politeness" to users I wonder about using Registry keys. I will be storing login and progress (bookmark) data. From any of you experts - is there any catch with using registry keys for AMS programs that will be used on systems ranging from win95 to xp? I read in an old forum message
"I have had a lot of success with reading the registry, but in several cases you have to be aware of the OS differences. Of course it is better to use a built-in function; IR has already done the job." However there were no more info on what these OS diferences might be. Does some of the more secure virus/firewall etc programs prevent you from writing to registry keys? If there is a more accessible less troubling location to store a little data? i realy do not care if the user can access and delete the file if he or she wants. in fact that would be a good thing.

Thanks again.

Alan

[Bruce]

Hey Alan-

I'm using INI files right now attempting to do the same thing, although I'm not gleaning info about the end user but, where they go on the CD.

http://www.indigorose.com/forums/showthread.php?t=11812

[Intrigued]

Alan, here is an example of how to write too and get from an .ini file. I added in comments to help explain how to accomplish such.

SEE: Attachment

[Intrigued]

Here is the updated project file from above. I have changed code in each of the three areas (Global Functions, On Preload, and On Show).

Now, there is a function that handles the incrementation of the 'Data' property in the INI file (.ini.txt).

[Alan vanBiervliet]

Thank you

Thanks a lot for the prompt help. I am very impressed with the community supporting AMS. I will try INI files to store and retrieve info. I am only collecting their name and completion of modules(true/false), nothing fancy.

Thank you again

Alan

[Intrigued]

I'm glad Bruce and I could get you started in the right direction Alan. :yes

[Derek]

Hi Alan

Just a couple thoughts:

I agree with the 'politeness' thing with regard to concerns for the end-user and of course, one should always try to stay on the good side of the end-user where possible. For this reason, many of us go out of our way to achieve this when, at times, there is clearly a quicker way to do something.
However, in a world where the registry is used so much by so many, it has become an accepted thing. For this reason, i would not hesitate to use it where possible - as i'm sure many others would too - given the ease of use.

This brings us to the different OS's point you raise. For the most part, the registry is at our mercy and you may add the values you need to any part of the registry that makes sense at the time. This pretty much eliminates the problem, as you can 'make up' a new key etc. that will be there what ever the OS version.

And so to the final point, "Does some of the more secure virus/firewall etc programs prevent you from writing to registry keys?"
I would tend to lean more toward the line of thought that user-privs will play the most part here, opposing the firewall theory - but of course, you raise a valid point, nonetheless.
As for the user-privs, there is always the 'run as' option to consider here.

Like i say, just a couple thoughts i wanted to share

[Dermot]

I agree with Derek. I have never had a program ask my permission to write something to the registry.

Dermot

[Corey]

True enough.

[csd214]

Alan, your quote "I have had a lot of success with reading the registry, but ..." looked familiar. Yes, that's my words in another post concerning how to get the user's My Documents folder. That's wasted effort to read the registry as long as I.R. has created an internal command (Shell.GetFolder(SHF_MYDOCUMENTS)) to find the value.

Your need is to create and reread your own values; you don't need to worry about how MS (or another vendor) has used the registry. I.R. has made it easy with the Application.SaveValue function. In fact it is too easy! IMHO, the help file should tell what you are actually doing (writing to the registry, HKCU\Software\Indigo Rose\ACData). Now we come to the "politeness". The help file should have declared: "As the author, when you create a Registry entry on the end user's computer, you are responsible of giving the end user a simple way to remove the entry."

Maybe I'm a fanatic when it comes to "housekeeping", but I really mean that we have to avoid cluttering the user's machine (with unnecessary folders/files and registry entries). It is disappointing, but there are a great number of installers, from well known companies, that are doing a lousy job. Especially when it comes to the uninstall process. "Why should the user want to uninstall our magnificent application?" Maybe they think like that; or they should have used Setup Factory to have a chance to understand what they are doing...

Alan, you are already advised by Bruce and Intrigued to use the INI method. I certainly agree; to use a text file option is a nice solution in your case. The INI file method is really simple and efficient.

You don't care if the user accesses (reads) your file, but if there had been a security issue, you could have used the Crypto plug-in.

There are no barriers; only possibilities.

[Corey]

we have to avoid cluttering the user's machine (with unnecessary folders/files and registry entries). It is disappointing, but there are a great number of installers, from well known companies, that are doing a lousy job. Especially when it comes to the uninstall process.

Also very true...

[rhosk]

I agree with Derek. I have never had a program ask my permission to write something to the registry.

Dermot

Me niether.

Spybot Search & Destroy has a running process that blocks unwanted registry entries, I use it all the time. You could not fathom the websites that try to write to the registry without permission. This is how some of the 'spies' infiltrate your computer, from homemade ActiveX controls to modifying your startup applications. The SBS&D process is called 'TeaTimer.exe". Even when installing certain software, a window will alert me and ask permission to write/change the registry. It goes without saying, but if you trust the source, you allow the modification. If it happens without your knowledge of source, then you can add it to a list to block permanantly.

[Corey]

Yep, Ron's right. I have TeaTimer running at all times (in conjunction with a couple other similar tools) and it's very good. :yes