/// <summary>try to dump whatever we've got in m_chars to m_props,
/// with a key of m_curPath.toString().
/// </summary>
protected internal virtual void tryToDumpDataToProps()
{
if ((m_curPath.size() >= 2) && (m_depthWithinUselessElement == -1))
{
/* m_curPath.toString() will be the property key whose value will be
* m_chars.
*
* This is (part of) what m_lastDumpedPath is for: With, for example "<ZYX.9>
* <PT.1>P</PT.1> </ZYX.9>" we might have had a m_curPath containing something
* like [ZYX, 0, 9, 0, 0] when we exited the PT.1 element. (note: internal
* DatumPath elements are 0-indexed, string representations of DatumPaths and
* the XML text is 1-indexed.) So in m_props the key for "P" would have been
* "ZYX[0]-9[0]-1-1". (the last "-1" is a default that got added by
* toString()).
*
* Then we would have exited the PT.3 element, changed m_curPath to [ZYX, 0,
* 9, 0], picked up the whitespace between </PT.3> and </ZYX.9>, and when
* exiting the ZYX.9 element, we might have written that whitespace to m_props
* with a key of the toString() of [ZYX, 0, 9, 0]; that is, "ZYX[0]-9[0]-1-1":
* the same as the key for the "P" ... clobbering "P" in m_props with
* whitespace.
*
* But since we know that HL7 fields / components / etc are always in order
* (numerically), we can count on m_lastDumpedPath and use
* DatumPath.numbersLessThan to avoid the clobbering.
*/
if ((m_lastDumpedPath.get_Renamed(0).Equals(m_curPath.get_Renamed(0)))?(m_lastDumpedPath.numbersLessThan(m_curPath)):true)
{
if (m_depthWithinUsefulElement >= 0)
{
// TODO: remove! or assert
if (SupportClass.ContainsKeySupport(m_props, "" + m_curPath))
{
System.Console.Error.WriteLine("ALAAAARM: CLOBBERING PROPERTY in " + GetType());
}
m_props["" + m_curPath] = "" + m_chars;
m_lastDumpedPath.copy(m_curPath);
m_chars.Remove(0, m_chars.Length - 0);
}
}
}
}
