What is the "catch" in writing Variants to a Binary file?

Question

I'm saving "event" data associated with an experiment that LabVIEW is "controlling".  The data includes such things as the State of several State Machines, Messages to Queued Message Handlers, digital data from hardware (such as Button Pushes), etc.  My "Event Type" is a cluster with three components -- Event Time (an I32 representing ticks of a 1KHz clock), Event ID (an Enum with values such as State, Message, Digital In), and Event Data, a Variant that is the State Enum or Message String or Digital U8 port value.
I wrote a test routine in which I generated some known data of Event Type, wrote it to disk using Binary Writes, then read it back in to an Array of Events doing a "Read to End-of-File" Binary Read.
Somewhat to my surprise, the array of Events looked exactly correct, including the Variant data.
What is the "catch" in storing data this way?  I can see one obvious problem -- if I change the Event ID Enum, I could mis-identify the Events.  Are there things I need to worry about in handling the Variant data?
[I'm now thinking about hare-brained schemes to save the Event ID data in the file, itself, perhaps as a header of some sort.  And before you ask, I'm not quite ready to think about using TDMS ...]

Answer 1

crossrulz wrote:
<snip>
The enum I will have to play with...  
<mini-snip>
Deleting and/or adding in the middle could mess things up.
Oh, yeah, I got a little burned with that one.  Good thing it was just something I was pracicing on.  Because changing stuff in the middle actually changes the values that the text is associated with, it can throw off all the the selections throughout your project!  I was dismayed to find all the typedef'd enum constants were changed to reflect the new text associated with the values.  For instance, if the value for "Init" was "1" and "Exit" was "2" and I added "Test" in between, "Test" would become "2" and "Exit" would move to "3" and all the contstants that had "Exit" selected before now showed "Test" as the selection!
So if you have to add something, add it to the end, no matter how unintuitive it makes the enum.  If you decide to delete something from the middle, don't delete it; replace it with something like <not used> to keep the values aligned with the text.  It may look funky on the enum, but it will save you lots of heartache.
Is there a better way to do this?
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.