Can't read FrSimEvent with FrSH/FrSE directed dump function

I wrote some FrSimEvent structures and was unable to read them back with using the self documenting structure definitions. Here is what was dumped out by FrameDump:

FrSimEvent (Instance: 0, Length: 181)
   name:  "sg00000003" 
   comment:  "SinGauss sg(A=8.24214e-21, F=355.158, Phi=0, Q=1, Width=6)" 
   inputs:  "" 
   GTimeS:  1234000016
   GTimeN:  896344576
   timeBefore:  0.00268875 
   timeAfter:  0.00268874 
   amplitude:  8.24214e-21 
   nParam:  5
   parameters:  1.26671e+18 0.0078125 1.89132e-307 2.91997e+194 8.34575e-309 
   parameterNames:  Caught exception: Unexpected EOF

The parameter names and parameter values should be the same as the argument list in the comment. The FrSH and FrSE structures for the FrSumEvent structure in the same frame are:

FrSH (Instance: 6, Length: 66)
   name: FrSimEvent
   class: 15
   comment: Simulated Event Data Structure
   chkSum: 932371767
FrSE (Instance: 81, Length: 51)
   name: name
   class: STRING
   comment: Name of event.
   chkSum: 1925915649
FrSE (Instance: 82, Length: 59)
   name: comment
   class: STRING
   comment: Descriptor of event
   chkSum: 1897555168
FrSE (Instance: 83, Length: 93)
   name: inputs
   class: STRING
   comment: Input channels and filter parameters to event process.
   chkSum: 1353525550
FrSE (Instance: 84, Length: 137)
   name: GTimeS
   class: INT_4U
   comment: GPS time in seconds corresponding to reference vale of event, as defined by the search algorigthm.
   chkSum: 1544414128
FrSE (Instance: 85, Length: 90)
   name: GTimeN
   class: INT_4U
   comment: GPS time in residual nanoseconds relative to GTimeS
   chkSum: -1707452790
FrSE (Instance: 86, Length: 90)
   name: timeBefore
   class: REAL_4
   comment: Signal duration before (GTimeS.GTimeN)(seconds)
   chkSum: -1489411559
FrSE (Instance: 87, Length: 88)
   name: timeAfter
   class: REAL_4
   comment: Signal duration after (GTimeS.GTimeN)(seconds)
   chkSum: 582310934
FrSE (Instance: 88, Length: 88)
   name: amplitude
   class: REAL_4
   comment: Continuouis output amplitude returned by event
   chkSum: -972228024
FrSE (Instance: 89, Length: 76)
   name: nParam
   class: INT_2U
   comment: Number of additional event parameters
   chkSum: 1120465800
FrSE (Instance: 90, Length: 104)
   name: parameters
   class: REAL_8[nParam]
   comment: Array of additional event paraameters(size of nParam)
   chkSum: 518067528
FrSE (Instance: 91, Length: 97)
   name: parameterNames
   class: STRING[nParam]
   comment: Array of parameter names (size of nParam).
   chkSum: 1471180268
FrSE (Instance: 92, Length: 51)
   name: data
   class: PTR_STRUCT(FrVect *)
   comment: 
   chkSum: 1623943097
FrSE (Instance: 93, Length: 53)
   name: table
   class: PTR_STRUCT(FrTable *)
   comment: 
   chkSum: -1872703952
FrSE (Instance: 94, Length: 55)
   name: next
   class: PTR_STRUCT(FrSimEvent *)
   comment: 
   chkSum: -1855509669
FrSE (Instance: 95, Length: 54)
   name: chkSum
   class: INT_4U
   comment: Struct checksum
   chkSum: 1579586363

These correspond to the structures and data types defined in the IGWD Frame specification (note especially the parameter value type is REAL_8). However, I notice that the parameter value type in the framecpp internal structure is REAL_4. If the values are being written to the frame files as REAL_4 values, the that would cause the FrameDump program to use unpredictable data as string lengths which would likely cause a failure like that seen above.