We were having so many problems with one of the external modules (the
one that does the storage and retrieval of the reference data) that we
decided to just bypass it and write our own data to files.
I've spent the better part of yesterday and today trying to write data
in a human-readable format so that the guys in the field can open up the
files and read them directly in excel. The easiest way to do that is a
.csv file, which is comma separated values, which means that my
file ends up looking like this:
Which is fine, as long as I can guarantee that there is no whitespace.
string1, hexnumber, hexnumber, hexnumber, hexnumber
Could really hose up the data.
I suppose I could make it more robust and put in a bunch more error
checking, but for its intended purpose, I think it's fine.
Having a string token in the first position made this more difficult,
because the normal stream commands read the ENTIRE line in as the
string. I then have to parse out the string first by separating out the
string token (strstr() is lovely for this), then get the rest of the
data by identifying the commas (strchr()).
Creating a directory programmatically has been a pain as well. For
instance, you can only create a directory one level deep. So if I wanted
to create something like "X:/dir1/dir2/", I can't just pass it that
string, I have to do two separate mkdir() steps. And it has to be
independent of the operating system. Windows wants backslashes, VxWorks
wants forward slashes.
But all things considered, I got this to work in just over one day. The
component that is being such a pain in the ass has been being developed
for almost ten months, and it's still not working.
Of course, I'm not writing every piece of data in the system to one big
XML file. For some reason, I think that's silly.