<t> a &lt; </t>

Fix for 11.4: in Markup.cpp:3076 insert code to set nCharWhitespace = 0 as follows:

  if ( pSource[nChar] == '&' )
  {
    if ( bAlterWhitespace )
      nCharWhitespace = 0;

    // Get corresponding unicode code point
    int nUnicode = 0;

<?xml version="1.0" encoding="utf-8"?>
<Properties>
  <MdlData>
    <Path>\DIR\PATH\</Path>
    <Name>0123_4567</Name>
    <Type>ABC</Type>
  </MdlData>
  <Parameters>
    <Parameter>
      <Name>XYZ_PART_NO</Name>
      <Value>
      </Value>
    </Parameter>
    <Parameter>

When reading [the Value element data], my code crashes.

str NavigateIterativelyXYZ_Generated( CMarkup mDocToNavigate )
{
  mDocToNavigate.ResetPos();
  str sXML = mDocToNavigate.GetDocFormatted(0);
  return sXML;
}

so when I run it, a window pops up and asks which document I wish to convert, shows me the output, all is good... except now, I wish to do this from a command line.

foxe –run align0.foal input.xml output.xml

Where align0.foal contains the foal program, input and output names will likely come from a batch script % parameter or such, and input.xml will contain the streamed xml and output.xml will contain the results of the GetDocFormatted(0). I'm thinking foal can be very powerful, am I missing a point in its implementation?

I'm loading about 3000 XML files, for a total of 99468934 bytes. I'm loading in the files myself and then passing the string to CMarkup. If I do that, and then loop down into every element in every file, it takes about 2 seconds (specifically, 1985ms), which I thought was pretty impressive.

However, if I do the same thing but also loop over every attribute on every element, it takes 8 seconds. I found this a bit surprising - obviously there's no additional file IO time or anything like that, it's all in string processing. The interface which CMarkup provides to access attributes is very string heavy - you need to get the attribute by name and then query the value using this name.

Is there a quicker way to loop over the XML attributes? I need the name and value for each attribute, but they can be in the order in which they occur in the file.

...I iterate the attributes for a single element with GetAttribName() and then call GetAttrib() to get their values.

The most noticeable change in this release of the editor is that the tree background is grayed out whenever you edit the text view. This is a visual cue to signify that the tree is out of sync with the text document to make it more self-explanatory why the behavior can be unexpected such as when you click into an element in the tree that no longer exists in the actual XML document text. But there are lots of actions that cause it to be parsed and synchronized again such as F5 Refresh and F7 Parse, or even F8 Format, File Save etc. However, when you are editing in the tree then both views remain in sync.

<item>
 text
</item>

I know I can just trim the returned string, but since whitespace isn't supposed to be pertinent in XML, I just thought the library should work this way. In the few cases where I need to preserve whitespace, I can use a CDATA encoding.

I've been successful splitting the file into 100,000 seperate files, named by the locality (using your tutorials). But patching them all together takes a long time, even if I automate it. A sample record below:

<listing key="1234567" status="active" updated="20090101T010101" type="residence">
  <title><![CDATA[Xyz Street, London]]></title>
  <supplementary-url><![CDATA[1234567.htm]]></supplementary-url>
  <description><![CDATA[AVAILABLE 01/01/2010. This
beautifully decorated place is situated on a quiet back
street of Xyz Garden in the heart of Xyz London.
The owners have refurbished to a particluarly high
standard paying exceptional attention to detail to the
overall finish and decoration. As the apartment is
situated on the Nth floor there are great views of
London giving the apartment excellent natural light.
Features available. We highly recommend a viewing.]]></description>
  <residence type="flat">
    <bedrooms><![CDATA[1]]></bedrooms>
    <bathrooms><![CDATA[1]]></bathrooms>
    <reception><![CDATA[yes]]></reception>
  </residence>
  <authority>
    <lease currency="GBP" term="private" visible="yes">
      <price term="weekly"><![CDATA[450]]></price>
    </lease>
  </authority>
  <address visible="yes">
    <country><![CDATA[GB]]></country>
    <subdivision><![CDATA[London]]></subdivision>
    <locality><![CDATA[London]]></locality>
    <postcode><![CDATA[AA1A 1AA]]></postcode>
    <road><![CDATA[Xyz Street]]></road>
  </address>
  <attachments>
    <photo title="" updated="20090101T010101" type="image/jpeg">
      <uri><![CDATA[1234567_354_255.jpg]]></uri>
    </photo>
    <photo title="" updated="20091118T201049" type="image/jpeg">
      <uri><![CDATA[23456789_354_255.jpg]]></uri>
    </photo>
    <photo title="" updated="20091118T201049" type="image/jpeg">
      <uri><![CDATA[34567890_354_255.jpg]]></uri>
    </photo>
  </attachments>
  <vendor>
    <name><![CDATA[Xyz Property Services]]></name>
    <phone><![CDATA[020 1234 5678]]></phone>
    <email><![CDATA[enquiries@xyz.example]]></email>
  </vendor>
</listing>

int ezcompress( ezbuffer& bufDest, const ezbuffer& bufSrc )
and similar...

I solved it by declaring the functions inline:

inline int ezcompress( ezbuffer& bufDest, const ezbuffer& bufSrc )
inline int ezuncompress( ezbuffer& bufDest, const ezbuffer& bufSrc )
inline int ezcompress( ezbuffer& bufDest, const MCD_STR& strSrc )
inline int ezuncompress( MCD_STR& strDest, const ezbuffer& bufSrc )

There's a problem in Markup.h, line 223: "#elif _MSC_VER >= 1000". As the version of VC++ 6.0 is 1200, MCD_FSEEK and MCD_FTELL are defined as _fseeki64 and _ftelli64. This causes 2 linking errors, e.g. "unresolved external symbol __ftelli64"

However, if I choose to "Use MFC in a Static Library", just the same as the sample project does, it's okay. But the size of execution file seems to be too big. So I changed the line 223 like this: "#elif _MSC_VER > 1200", and the problem is solved. I also try version 11.0 of CMarkup and there's no such problem, because it define MCD_FSEEK as _fseeki64 only when _MSC_VER is bigger than 1400 (VC++ 2005).

I would suggest that for VC++ 6.0, it's better to define MCD_FSEEK and MCD_FTELL as fseek and ftell, rather than _fseeki64 and _ftelli64

xmlOutput.Open( "test" + "_" + [Child value from REFERRAL_ID] + "_" + nFileCount + ".xml", MDF_WRITEFILE );

My xml [not real data] is:

<REFERRAL_DISCHARGE>
  <FILE_VERSION>1.0</FILE_VERSION>
  <REFERRAL_ID>1234</REFERRAL_ID>
  <ORGANISATION_ID>ORG-5678</ORGANISATION_ID>
  <ORGANISATION_TYPE>005</ORGANISATION_TYPE>
  <EXTRACT_FROM_DATE_TIME>2009-06-01T00:00:00</EXTRACT_FROM_DATE_TIME>
  <EXTRACTED_DATE_TIME>2009-06-30T15:40:15</EXTRACTED_DATE_TIME>
  <TEAM_CODE>5555</TEAM_CODE>
  <EVENT_HCU_ID>XXX1234</EVENT_HCU_ID>
  <SEX>M</SEX>
  <DATE_OF_BIRTH>1900-05-05</DATE_OF_BIRTH>
  <REFERRAL_FROM>UN</REFERRAL_FROM>
  <START_DATE_TIME>2008-12-24T00:00:00</START_DATE_TIME>
</REFERRAL_DISCHARGE>

The parent is REFERRAL_DISCHARGE, I need the file name exactly how you have it plus the individual value from REFERRAL_ID to make it easy to link to the data included.

We are a not-for-profit organization and we have to report to the [New Zealand] Ministry of Health and our data is to be packed as individual xml files. We are not dealing with huge files (this one was only 316kb) and also they are relatively simple extracts, but I don’t know in the future... it may get more complicated.