|
|
Get a life.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
I have a life, and in my life I don't put CString in my headers. I am so tired of seeing this. By putting CString in your interface, you force your clients to to use MFC or WTL or something with CString. Use LPCTSTR in your interface and if you must, use CString in your implementation.
|
|
|
|
|
I gave out the source code so if you don't use MFC go change it yourself!
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
I knew it would be pointless to even say anything.
|
|
|
|
|
Not to mention that this forces you to use VC6 if CString are compiled in library's compiled with VC6. I also realy hate it. havent we learned to use 'const char*' ?
|
|
|
|
|
Anonymous wrote: I knew it would be pointless to even say anything.
Why did you say something then? Instead of being grateful, cry on.
|
|
|
|
|
Personally, I use MFC and use CString everywhere. If you do not use MFC then simply modify the code yourself. What is the problem?
|
|
|
|
|
|
Anonymous wrote:
How lame
It is hard to beat an Anonymous poster who has probably never written an article for CP nor contibuted in any usefull way who can't even go to the trouble to spell out what his problem is. Talk about lame.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
I think, when you were discussing XML vs Registry issue you all forgot that Registry as it implemented is Direct access Database -- meaning you can just change or read just one record without rewriting the whole file...
How would you do it in XML may I ask???...
So, I would say: when efficiency and replication is an issue -- Use Registry... When code portability is of great concern -- use INI file and XML if you want...
However, I didn't encounter any portability reasons in my own work however...
GL
I
|
|
|
|
|
My applications use both the registry and XML, as follows:
HKEY_LOCAL_MACHINE\SOFTWARE\... : User-agnostic application settings
HKEY_CURRENT_USER\Software\... : User-specific application settings
XML : User 'documents'
Admittedly, our documents are relatively small (< 256K), which means the DOM is perfectly adequate for loading/saving them.
As far as support issues go, why not provide a little application that can export the relevant registry contents for the user? If you wanted, you could make it smart enough to export the registry stuff, accumulate system information, accumulate VERSIONINFO stuff from your application, and package it all up and e-mail it to your support folks. If your product is big enough, something like this would pay for itself in short order by providing 99.7% of the info the support person needs.
"Think of it as evolution in action." - 'Oath of Fealty' by Larry Niven and Jerry Pournelle
|
|
|
|
|
Gary Wheeler wrote:
As far as support issues go, why not provide a little application that can export the relevant registry contents for the user? If you wanted, you could make it smart enough to export the registry stuff, accumulate system information, accumulate VERSIONINFO stuff from your application, and package it all up and e-mail it to your support folks. If your product is big enough, something like this would pay for itself in short order by providing 99.7% of the info the support person needs.
Nos you're thinking. There are several application that do just that but may not use XML.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
Hi There
I became extreme happy this morning, when I "felt" over this article, but I can't compile the demo project, because I missing XmlSettingsTest.rc.
Thanks in advance,
Best Regards
Søren Madsen
Denmark
|
|
|
|
|
its updated now
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
It's ok to have a system exactly like this article mentioned. Of course it depends upon the application that is using it and how it is being used.
For example, I create in-house tools that are used by users that are always at the same computer. So there are no issues in regards to multiple users on the same computer.
We use a similar xml based profiling system. It make development easier. If I suspect a users xml file is causing trouble, I simply ask them to email me their file. No need to access the registry which is confusing to most users.
Code like this is simply another option based on a needed task.
|
|
|
|
|
Why on earth are you all using XML DOM? It is so slow and resource consuming. Don't you know about the SAX2? (Example: when parsing the 100kb XML file with DOM, the engine allocates approx. 1mB of memory). SAX not only reads XML, it can write with XMLWriter.
|
|
|
|
|
For one thing, you probably shouldn't have a configuration settings file thats 100kb. The DOM should work fine for small config files.
Secondly, yes I do know about SAX but I haven't used it much. The DOM is quick and easy for the novice to pick up and use.
YoSilver wrote:
SAX not only reads XML, it can write with XMLWriter.
You know what, that's a great idea for an article so why don't YOU write it!
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
One of the many reasons Microsoft implemented the registry was to eliminate all of the INI files that applications created in system- and program-specific areas. As one comment mentioned, anyone who has ever tried to write software that will function properly in a multi-user environment can attest to how well the registry works.
The registry contains two general areas that you should save program settings into: HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER . The local machine area, as the name implies, is for storing program information that all users of the system will need. The current user area is for storing user-specific data. In a multi-user and multi-system environment, the user's registry generally follows the user from one machine to another. This used to be called a "roaming profile" in the Windows 95 days.
To mimic this using XML, you would need to save one file in a system-specific area, and another in a user-specific area. Both of these do exist, in the form of the C:\Documents and Settings\All Users\Application Data\ and C:\Documents and Settings\username\Application Data\ directories, but there is a problem: replication.
Many Windows shops will replicate a user's registry settings when the user logs in and out of various workstations. Replicating files is less common. Why? Simple: Most users create an inordinate amount of files in their "My documents" folder. This is good, because it provides a backup server with a single place to look when making a backup from the system. However, if full replication is used, all of these files are transferred between the Domain Controller and the workstation at every log on and log off. This is a huge waste of bandwidth! On my LAN at home, I set the systems to replicate all user profile data except for the "My Documents" folder. On 100 Mbps, it takes 15 seconds to get on or off a workstation because of the amount of data being transferred.
So, to end my rant with my opinion on this subject as both a software developer and a systems administrator: Follow Microsoft's recommendation. Software developers should save program settings in the proper area of the registry. By creating subkeys, one can have heirarchical storage of the data with very little additional effort. Plus, it enables program settings to be carried from one system to the next using replication. In the business environment, these are all important things to keep in mind.
XML was originally intended as a data description and transfer mechanism, not as an actual storage format. The registry may not be human-readable without a tool like RegEdit, but it was intended to be efficient, and store many different types of data in a heirarchical fashion. Duplicating this with text (XML) files doesn't accomplish anything beneficial.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
Duplicating this with text (XML) files doesn't accomplish anything beneficial.
I disagree, mainly because RegEdit is not a good tool for the lay-person. The registry is too big, cumbersome and dangerous to have your clients playing with when they call in for tech support.
Also, it appears that MS is going to recommend XML .config files in .NET.
Admittedly, XML is not good for very large sets of preferences.
In the end, it's up to the developer.;)
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
I disagree, mainly because RegEdit is not a good tool for the lay-person. The registry is too big, cumbersome and dangerous to have your clients playing with when they call in for tech support.
Jason, I think you're forgetting one important thing: Users should not be messing with the registry in the first place! It is supposed to be a place where applications can store configuration and state information, and nothing more.
Even as a software engineer, I rarely find a need to work within the registry. I have never found a reason to tell one of my customers to use RegEdit to fix something related to one of my applications. If you have had that experience with your customers, then you should spend more time on your design!
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
Users should not be messing with the registry in the first place!
Exactly! But in the real world they do sometimes. The apps our company writes are quite large and the users aren't computer savvy. We do use the registry (too much IMO) and on occasion, we have had to look at the registry for many reasons.
Paul A. Howes wrote:
Even as a software engineer, I rarely find a need to work within the registry.
Really? I'm willing to bet you are in the minority.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
Totally agree. It is a good practice to choose whatever is good for your project instead of follow M$ for everything they recommend.
|
|
|
|
|
> The registry is too big, cumbersome and dangerous to have your clients
> playing with when they call in for tech support.
Maybe the solution to this is to store your settings in the registry as usual, but add a button somewhere in your program labeled "Export Program Settings" (part of, say, a dialog box called by a Tech Support button in the About box, like the Office apps).
Have this button create a simple .REG file that your users can email back to you... Doesn't RegEdit even have some command-line parameter to export a subkey in a non-interactive mode (no UI)? That's what I'm thinking but for some reason I can't find the docs right now...if that's the case, that'd be just a matter of spawning RegEdit from your own program, so that'd be, what, two lines to write? and (you'd assume!) bug-free from the start. Reimporting the file if necessary would be just as easy.
Just to add to the conversation, I'd have to agree with going against XML for storing program settings; for one thing, a *big* assumption is that the proper DLLs are already installed on the client machine...if the program you're writing isn't already using XML for some reason, why drag along the entire redistribution package just for storing the program settings? But if you already have another reason for using XML in your program, fine, but as others have pointed out, you may run into multi-user/multi-location problems. Using the <profile>\AppData directory is an idea, but then what are you going to fall back to on OSes that didn't even have that directory? Heck, even My Documents didn't exist on 95.
While I don't disagree that sometimes you need to have program settings forwarded to tech support, I don't believe XML is really the answer. I don't want to discredit Jason or undermine his efforts, so I'll say this much--the article is providing a very decent intro to XML manipulation in C++. So, thanks!
- DanielD
|
|
|
|
|
To each his own.
Jason Henderson start page articles "If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|