The consensus in our organization (and most of our friends/clients) is to use either INI files or XML. XML requires some library support that may or may not be easily accessible from MapBasic. I've not tried it. In MB I'm an INI kind of guy.
-----Original Message----- From: Bill Thoen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 15, 2004 2:08 PM To: MapInfo-L Subject: MI-L OT - Windows Programming Philosophy While developing some MapBasic code to support Windows API calls to access private profile files (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo /base/registry_functions.asp?frame=true) I ran across a Microsoft warning that says that using private profiles (those *.ini files) is no longer in fashion and that now we should always use the Registry to store parameters for programs. My feeling is that the Registry is already pretty stuffed with loose toys, and putting everything into that one system is unwise. However, I don't want to let my ignorance get me into trouble someday, so I thought I'd ask for opinions. What do other developers think about using the Registry instead of ini files for MapBasic apps? Is it a black and white issue, or ar there reasons for using an ini file sometimes, and the Registry at other times? Is a centralized repository of configuration data a better model than using distributed ones? Does anyone have any good arguments pro or con on this? Or should we do it simply because Microsoft says so? I suppose if they've lost interest in ini files, it might be a good idea to not to use them. - Bill Thoen --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13357 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13365
