I wrote a screensaver, via Visual Studio 2003 in C# and I decided a wiser
choice for me was to use an xml file to save my configs. Btw: I wonder if
this is why every bit of documentation I've found for saving configuration
info in an xml file speak of only doing this for web programming in fact, I
get the impression that they have been slipped a mickey that made them
forget that there are programs out there that are not web based, but I
digress ...
I could have done a regular config files be just a regular text file, but I
figured, I might as well do it with xml like everyone else is doing, so
remove all my registry config saving stuff and replace it with a simple
class that uses an in-memory only dataset and table tries to read the xml
file named "SwarmIni.xml" and if it doesn't exist, create one by building
the config schema on the in-memory table, and then populating a row or rows
with my config data and create the file. WriteXml over-writes the xml file,
so I didn't have to worry about deleting the file.
It worked fine as long as I named the file swarm.exe, the file and the
config screen would track. However, when I renamed the exe to .scr all kinds
of strange things would happen. First, I would watch it create the xml
values, I would bring up config and change a value, shut down the
screensaver, reload it and see that the new values were there, and then I'd
get curious and open up the xml with notepad and find the OLD values there!!
Notice I say that it worked normally as long as it ended in exe but seemed
to be working with some sort of ghost-xml file with new values AND create a
visible xml file that did not track with my config changes. It was not a
case of different names, the file name was a constant, in only ONE place in
the program.
It was as if windows was kidnapping the xml file!! Despite doing a search
telling it to include system32 and all system subdirectories, it would find
any file except xml files, even non-xml files in system32 but it would not
find that file I was seeing right there in front of my face! Now ain't this
strange??
I solved it! I simply included the application path so that the config.xls
file created was SwarmIni.scr.config.xls and then no matter how I named the
extention, the data in the config screen, and that in the xml file would
track.
So, while I never ever did find out what was happening, I did cure it by
specifying the path. I suspect that windows is kidnapping a copy of the xml
file and redirecting things some how. I still can't get search to find my
xml files tho. I have show hidden and show system files turned on.
I learned three important rules of xml programming ....
1. Always specify a path, never just give it a name and trust it to create a
file in the location you expect, without this bizarre non-tracking behavior
cropping up.
2. Never, ever copy your write method to the read method and change the name
of the method and the code to do the reading. What I did by accident, was
that I had the read method, callling the write method IF the file did not
exist, which was fine and dandy, but in the branch I executed when the file
already existed, I had a read early on and a spurious DataTable.WriteXml
call, but writing an xml file while my xml helper class was supposed to be
reading, and hadn't disposed of the table doing the reading yet, caused some
strange feedback loop to start. My program would appear to execute, but some
process would end up looping, and my hard drive light would start thrashing
like crazy. There was no visible process, and the every time I ran my saver,
everything looked ok, but my computer would flash, lag, the hard drive would
do more and more thrashing, creating nothing that I could see and all kinds
of strange things would happen which are too many to list ...
3. It is unfortunate that xml is so similar to xls - excel's spreadsheet
extention. I have to be extremely careful not to accidentally name something
as xls instead of xml. In C++ I would have created a global #define in one
place and forget about it, but in C# there isn't such a thing as a global
constant visible throughout all the projects in a solution, so be careful
out there!
4. I am a bit wary about this saving config info in xml format tho. Sure,
it's portable, and its nice to read it and locate values, but it's also
portable to malware that might be able to read those value and change them,
and perhaps cause some sort of havoc by trying buffer over-runs and other
stuff. In other words, I worry about this, that it might create a security
hole here. An ini file I write, could have been in any format, and could
have anything in it in any order, but an xml file, is predicable, and
standard, and makes it an easy pickins target. Don't get me wrong, I don't
dislike xml format. It's great for moving data and sharing it, but I wonder
if it's such a great place to store config info. I think more security needs
to be put into place. Perhaps xml with encrypted contents?
RambleMode = Off.
--
To reply to this message take off the .NoJunkSpam off of the end of
ga******@pacbell.net.NoJunkSpam
