Fixes for whitespace trimming/collapsing, and file read mode, as well as some changes in compiler #ifdef handling for WIN32.

Summary:

• QT Windows compiling
• end-of-line options
• fix: trim whitespace escaped chars
• fix: 64-bit compiler warnings for MCD_BLDLEN
• fix: (Dev only) file read mode bug

Details:

Using CMarkup with QT on Windows is easier now; you shouldn't have to do any tweaking of CMarkup to add it to your QT project. The changes involved special cases for GNUC when it is used on Windows. Either the WIN32 (Windows.h) or _WIN32 (Visual Studio) precompiler defines will let CMarkup know it is compiling for Windows.

In 11.3 and 11.4, MDF_TRIMWHITESPACE and MDF_COLLAPSEWHITESPACE would remove an escaped char at the end of the trimmed data (see 11.3 Bug: trim whitespace removes escaped value).

On Linux and OS X, lines generated by CMarkup will now end with a newline by default instead of a Windows style CRLF (carriage return line feed), and the end-of-line setting can now be directed with preprocessor definitions. If you are on a non-Windows platform and want your CRLFs back, now you must add MARKUP_EOL_CRLF to your preprocessor definitions.

End Of Line Defines
Name	Value	Description
MARKUP_EOL_CRLF	MCD_T("\r\n")	Aka 0d 0a, this is the default for Windows builds
MARKUP_EOL_NEWLINE	MCD_T("\n")	Aka 0a, this is now the default for non-Windows builds
MARKUP_EOL_RETURN	MCD_T("\r")	Aka 0d, this is rarely used
MARKUP_EOL_NONE	MCD_T("")	For minimal size, documents will be on one line, but GetDocFormatted will not produce desired results

The file read mode bug occurred with elements over 32k long that did not have child elements. This problem was only in file read mode where the Open method is used with MDF_READFILE. See File read GetSubDoc incomplete.

See also previous CMarkup release notes: 11.4, 11.3, 11.2, 11.1, 11.0, 10.1, 10.0, Archived CMarkup Release Notes

An important fix to the 11.3 whitespace features, improvements in the GetDocFormatted method, and an enhancement to HasAttrib.

Here's the list of 11.4 enhancements:

• fix: MDF_TRIMWHITESPACE and MDF_COLLAPSEWHITESPACE were crashing on values that were only whitespace... sorry, a glaring hole in the test cases
• GetDocFormatted now removes any space between the attribute name and value (and has improvements in speed and memory efficiency)
• HasAttrib can now return the attribute value as well, making it an alternative to GetAttrib for convenience and performance
• fix: rare HTML parser case for attributes without values in empty start tags, e.g. <A a/>

See also previous CMarkup release notes: 11.3, 11.2, 11.1, 11.0, 10.1, 10.0, Archived CMarkup Release Notes

Release 11.3 Date: November 20, 2010, download

A performance improvement makes CMarkup significantly faster! Overall parsing speed is up 35%, and attribute methods are twice as fast as 11.2. This release also includes document flags to trim whitespace and collapse whitespace.

Here's the list of 11.3 enhancements:

• overall parser performance increased about 35%, see CMarkup XML Parser Performance
• attribute method performance improvements
• New method GetNthAttrib retrieves name and value of attribute 0, 1, 2...
• use MDF_TRIMWHITESPACE and MDF_COLLAPSEWHITESPACE to affect retrieved values (see Whitespace and CMarkup)
• fix: bug in Linux/OS X TextEncoding::IConv *thanks Frank Dering
• performance measures added to the tests and CMarkupTesting.xml output (see CMarkup test dialog)

See also previous CMarkup release notes: 11.2, 11.1, 11.0, 10.1, 10.0, Archived CMarkup Release Notes

Switch	Purpose
-new	open in a new instance of the editor (useful when single instance preference is selected)
-same	open in the existing instance of the editor
-watch "C:\event.log"	open file in read-only auto-reloading mode to view the tail of log files
-line 23	open file at a line
-offset 451	UTF-8 offset from beginning of document or from beginning of line if line is specified
-fromoffset 5	pre-select text from this offset to specified offset
-run script.foal:f arg1 arg2	execute the script without showing the editor

Examples:

foxe.exe "C:\XML examples\file.xml" -line 6

foxe.exe file.xml -line 6 -offset 5

foxe.exe -offset 240 -fromoffset 235 file.xml

foxe.exe -watch C:\event.log

foxe.exe -run C:\script.foal

foxe.exe -same file.xml

"C:\Program Files\firstobject\foxe.exe" -new file.xml

As of release 2.4.1 the free firstobject XML editor has a command line switch to run a script:

foxe -run "C:\foal scripts\script.foal"

It generates 2 files, foxe_err.txt and foxe_out.txt. The err file contains marked up information about the run and can help diagnose issues with running. The out file contains the output returned from the script in the return statement.

And with release 2.4.2 you can specify function and arguments, see below.

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

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

Update April 23, 2011: With release 2.4.2, it works the way it should (the way Garth described). The -run command line option passes any number of command line arguments into the parameters of the function in the foal script. For example (remember to use quotes if a path or argument contains spaces):

foxe -run "C:\foal scripts\script.foal" C:\in.xml C:\out.xml

Here is a script to format XML that works with the previous command line:

formatxml(str sInPath, str sOutPath)
{
  CMarkup m, r;
  r.AddElem( "load", sInPath );
  m.Load( sInPath );
  r.AddSubDoc( m.GetResult() );
  if ( ! m.SetDoc(m.GetDocFormatted()) )
    r.AddSubDoc( m.GetResult() );
  r.AddElem( "save", sOutPath );
  m.Save(sOutPath);
  r.AddSubDoc( m.GetResult() );
  return r;
}

Bascially this script just loads the input file, calls GetDocFormatted and saves to the output file (you could also add an argument to pass format flags). In addition it returns the results in case something goes awry you can see what happened in foxe_out.txt. If there is no problem, it might look like this:

<load>C:\in.xml</load>
<read encoding="UTF-8" length="31579"/>
<save>C:\out.xml</save>
<write encoding="UTF-8" length="29958"/>

If there are multiple functions in a script, you can name your entry function main to avoid confusion about which function is being called. You can also specify the entry function explicitly on the command line with :function at the end of the script filename. Specifying the function allows you to invoke multiple functions in one script from the command line. Here is an example of using the same script to perform different operations:

foxe -run C:\script.foal:extract London

foxe -run C:\script.foal:merge London "New York"

If you specify a function name that is not found in the script, there will be an indication at the bottom of foxe_err.txt that also indicates the entry point it would have used if you had not specified one:

<entry_point arg_count="2" not_found="gormatxml">formatxml</entry_point>

If you do not specify the function and there is no main function in the script, the last function with a matching number of arguments is called. It chooses the last matching function because functions earlier in the script tend to be subroutines since in FOAL you can only call functions below where they are defined. ]]> http://www.firstobject.com/whitespace-and-cmarkup.htm whitespace-and-cmarkup.htm Sat, 20 Nov 2010 23:11:00 GMT CMarkup Articles  

<item>
 text
</item>

With release 11.3 you can set flags to trim whitespace or collapse whitespace when reading values from the document. CMarkup is unusual among XML tools because it simply preserves all whitespace, but now it can also support standard ways that XML and HTML processors alter whitespace.

Whitespace includes spaces, tabs, returns and newline characters. CMarkup has always preserved the whitespace as it appears in the document, and it still will. These new flags give you the option of reading the trimmed or collapsed text values, but the document is not altered, so you can turn off the flags and go back to reading the preserved whitespace.

Document Flag	Purpose
MDF_TRIMWHITESPACE	removes leading and trailing whitespace
MDF_COLLAPSEWHITESPACE	removes leading and trailing whitespace, but also replaces all segments of whitespace inside the text with a single space; so for example a newline and tab within the text will become a single space

These flags affect CMarkup methods like GetData and GetAttrib that retrieve element data, text nodes, and attributes (but not methods like GetSubDoc and GetElemContent that return XML i.e. markup text).

These flags have no effect on text retrieved from CDATA Sections. With CMarkup you can create elements to contain CData Section text to protect the whitespace from ever being altered by CMarkup or any other XML tool:

xml.AddElem( "Prose", strProseText, CMarkup::MNF_WITHCDATA );

Turn the whitespace flags on and off anytime without performance penalty if for example you want to trim some values and not others. Use SetDocFlags to set these flags.

CMarkup m;
m.SetDocFlags( CMarkup::MDF_TRIMWHITESPACE );

You can OR a flag with GetDocFlags if you don't want to affect other flags:

m.SetDocFlags( m.GetDocFlags() | CMarkup::MDF_COLLAPSEWHITESPACE );

Turn off a flag without affecting others as follows:

m.SetDocFlags( m.GetDocFlags() & ~CMarkup::MDF_COLLAPSEWHITESPACE );

These whitespace flags can affect values returned by GetData, GetAttrib and related methods. They also affect methods like FindElem that search for a path specifying a value in a path attribute predicate (see Paths In CMarkup) because values from the document will be trimmed or collapsed before being compared to the specified value.

See also:
Node Methods in CMarkup
]]> http://www.firstobject.com/generate-file-names-xml-splitter.htm generate-file-names-xml-splitter.htm Sat, 20 Nov 2010 23:10:00 GMT XML Editor Articles An example of how to use the free firstobject XML editor to split XML and then name the output files based on information in the pieces separated by the XML splitter script. Maybe this will be useful to other NGO's who need to split their XML.

<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>

For splitting an XML file less than 10MB into a lot of referral discharge files, this is the easiest way to do it:

split()
{
  CMarkup xmlInput, xmlSubDoc;
  xmlInput.Load( "input.xml" );
  int nFileCount = 0;
  while ( xmlInput.FindElem("//REFERRAL_DISCHARGE") )
  {
    ++nFileCount;
    xmlSubDoc.SetDoc( xmlInput.GetSubDoc() );
    str sID = xmlSubDoc.FindGetData( "//REFERRAL_ID" );
    str sFilename = "test_" + sID + "_"+ nFileCount + ".xml";
    WriteTextFile( sFilename, xmlSubDoc.GetDoc() );
  }
  return nFileCount;
}

Splitting a huge file

For others who have really large files (especially over 100MB up to any number of gigabytes) use the XML reader mode which processes the source file on disk very efficiently. The only difference from the above script is opening the input file in read mode rather than loading it all into memory.

split()
{
  CMarkup xmlInput, xmlSubDoc;
  xmlInput.Open( "input.xml", MDF_READFILE );
  int nFileCount = 0;
  while ( xmlInput.FindElem("//REFERRAL_DISCHARGE") )
  {
    ++nFileCount;
    xmlSubDoc.SetDoc( xmlInput.GetSubDoc() );
    str sID = xmlSubDoc.FindGetData( "//REFERRAL_ID" );
    str sFilename = "test_" + sID + "_"+ nFileCount + ".xml";
    WriteTextFile( sFilename, xmlSubDoc.GetDoc() );
  }
  xmlInput.Close();
  return nFileCount;
}

A note about usage of the anywhere path. If you want to grab multiple pieces of data like xmlSubDoc.FindGetData("//REFERRAL_ID") remember that the // anywhere path starts from the current position. So if you're not sure about the order of the data you are grabbing, call xmlSubDoc.ResetPos() in between calls to FindGetData.

<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>

To find all the matching records on a huge file you do something like this: from the File menu select New Program, paste in the following script, and modify the input file pathname (note that for C++ syntax, use a double backslash for backslashes in the pathname).

pull_by_locality()
{
  str strSearch = "London";
  CMarkup xmlInput, xmlListing, xmlOutput;
  xmlInput.Open( "C:\\huge.xml", MDF_READFILE );
  while ( xmlInput.FindElem("//listing") )
  {
    xmlListing.SetDoc( xmlInput.GetSubDoc() );
    if ( xmlListing.FindGetData("//locality") == strSearch )
      xmlOutput.AddSubDoc( xmlListing.GetDoc() );
  }
  return xmlOutput.GetDoc();
}

To export the result document as London.xml:

xmlOutput.Save( strSearch + ".xml" );

To delete (or actually skip) records which are no longer required e.g. we want them if status is "active" but not if it is "inactive" or "sold":

xmlListing.ResetPos();
if ( xmlListing.FindGetData("//status") != "active" )
  ...

To change an element tag name from title to topicname in the output, first add the new element with the same content, then remove the old one (this is the easiest way to make sure the new element goes into the same position as the removed one).

xmlListing.ResetPos();
if (xmlListing.FindElem("//title"))
{
  xmlListing.AddElem("topicname", xmlListing.GetData());
  xmlListing.FindPrevElem(); // title
  xmlListing.RemoveElem();
}

As far as inputing the search string, FOAL scripts don't support dialogs yet. However, you can automate the process if you can put the search string in a file such as search.txt which could be retrieved in the FOAL script with:

str s;
if ( ReadTextFile("C:\\search.txt", s) && StrLength(s) > 2 )
  s = StrMid( s, 0, StrLength(s)-2 ); // remove CRLF
str strSearch = s;

In DOS, if you had a script named search.foal, then you could create a search.bat file as follows to let you type search London on the command line.

echo %1 > C:\search.txt
"C:\Program Files\firstobject\foxe.exe" -run C:\search.foal

Here's an interesting diagnostic to count instances of each locality:

locality_tally()
{
  CMarkup xmlLocalities, xmlInput;
  xmlInput.Open( "huge.xml", MDF_READFILE );
  while ( xmlInput.FindElem("//locality") )
  {
    str sLoc = xmlInput.GetData();
    int n = 1;
    if ( xmlLocalities.RestorePos(sLoc) )
      n = StrToInt(xmlLocalities.GetAttrib("n")) + 1;
    else
    {
      xmlLocalities.ResetPos();
      xmlLocalities.AddElem("locality",sLoc);
      xmlLocalities.SavePos(sLoc);
    }
    xmlLocalities.SetAttrib("n", n);
  }
  return xmlLocalities;
}

Would yield a result like this:

<locality n="890">London</locality>
<locality n="431">Yorkshire</locality>

xmlOutput.SetDoc("");

Call GetNthAttrib to get the string name and value of the Nth attribute in the main position element. The first attribute is 0, the second is 1, etc. If there is no current position or the current position node does not have the specified attribute, it returns false.

Similar to GetAttribName, this method lets you iterate through the attributes of an element or processing instruction. However, this is usually better because it provides the attribute value without an additional call to GetAttrib, and it returns a bool which is convenient for looping. For example:

MCD_STR strName, strAttrib;
int n = 0;
while ( xml.GetNthAttrib(n++, strName, strAttrib) )
{
  // do something with strName, strAttrib
}

GetNthAttrib also works when the main position is a processing instruction node with attributes. See Node Methods in CMarkup.

Release	Chart	parse doc/attrib		create doc/attrib		Units
CMarkup 11.2		40002	5175	12331	4754	b/ms
CMarkup 11.3		54042	9195	14394	6820	b/ms

Since these measurements do not involve disk I/O, the speeds are measured in character units per millisecond where the character unit is b for byte, w for word (2 bytes), and dw for double word (4 bytes), depending on the build and platform. In the first chart I include 2 parse tests and then 2 corresponding create tests.

	parse document	this is the core indicator of parsing speed; the document string is passed to SetDoc in memory and parsed, it is not loading the document from disk
	parse attributes	loops through the document reading all attributes with GetAttribName and GetAttrib (the new GetNthAttrib method is more efficient way to do this)
	create document	builds a document using an AddElem and SetAttrib for each element, the document is not saved to disk, there is no disk I/O in this measurement
	create attributes	creates a document with up to 4 randomly selected attributes and values per element, the SetAttrib call occassionally overwrites an attribute

The reason for release 11.3 performance improvement

One of the most intensively used operations in the parser is determining whether a character is one of a set of characters. In 11.3 I replaced MCD_PSZCHR (strchr) with a lookup define which is an order of magnitude faster and yields a roughly 30% speed improvement in overall raw parser speed. The new lookup define only checks the bounds and then returns the offset in the array, where c is the character, f and l are the bounds (first and last) and s is the lookup array (a string):

#define x_ISONEOF(c,f,l,s) ((c>=f&&c<=l)?(int)(s[c-f]):0)

So, for example, a whitespace check uses x_ISONEOF and passes the bounds 9 and 32, and a lookup string array for the range between those bounds:

// classic whitespace " \t\n\r"
#define x_ISWHITESPACE(c) x_ISONEOF(c,9,32,
  "\2\3\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1")

Another roughly 5% overall improvement was gained by replacing MCD_PSZNCMP (strncmp) with a simple speedy implementation of string compare.

Comparing different builds of release 11.3

Build configuration makes a big difference in performance. See ANSI and Unicode files and C++ strings and non-Unicode text handling in CMarkup for discussions of string character set options.

Build	Chart	parse doc/attrib		create doc/attrib		Units
MFC (UTF-8)		54042	9195	14394	6820	b/ms
STL (UTF-8)		55923	9193	11583	6061	b/ms
MFC MBCS		14424	3269	11084	3492	b/ms
STL MBCS		14783	3137	8636	3223	b/ms
MSXML6 MFC MBCS		3832	1762	1849	1347	b/ms
MFC WCHAR		57405	8607	14530	6594	w/ms
STL WCHAR		57780	8607	10744	5639	w/ms
MSXML6 MFC WCHAR		3950	1939	1963	1428	w/ms

Using Unicode (either UTF-8 or WCHAR) strings in memory is much more efficient than MBCS which utilizes Windows APIs to determine character boundaries according to the locale character set. MSXML is very slow due to the overhead of COM and is slightly faster in a WCHAR build which avoids conversion to and from COM's WCHAR-based strings.

File mode performance

Unlike the measurements above, the XML reader and XML writer measurements are all in bytes per millisecond regardless of build because they are based on the file I/O rather than the in-memory character unit size. The file is UTF-8, which means the MBCS and wide character builds have the extra penalty of character set conversion. The MBCS conversion can be done using the libc (stdlib.h) function wctomb (not using the Windows API).

Build	Chart	XML reader	XML writer	Units
MFC		15086	11528	b/ms
STL		13858	9540	b/ms
MFC WCHAR		10854	8757	b/ms
STL WCHAR		10717	7509	b/ms
MFC MBCS		11673	9846	b/ms
STL MBCS		10444	8137	b/ms
MFC MBCS libc		2231	2844	b/ms
STL MBCS libc		2155	2677	b/ms

See also:
Archived CMarkup Performance Tests
Attribute Method Performance

* Measurements here are representative of the speed with my own sample data on a 1.7GHz 1GB Vista netbook. Running these tests twice in a row often gets slighly different results because they are affected by variations in CPU.

In its attribute methods, in every call CMarkup reparses attributes up to the one that is accessed. This can lead to poorer than expected performance when you have attribute intensive code, i.e. code that repeatedly accesses or checks for many attributes. This is due to an original design trade off: CMarkup does not store attribute indexes.

CMarkup release 11.3 introduces a new method GetNthAttrib which is twice as efficient as GetAttribName combined with GetAttrib, and in addition attribute parsing is about twice as fast (see CMarkup XML Parser Performance). So, iterating the attributes in your case might be reduced from 6 seconds to 1.5 seconds.

I did design a solution to manage and reuse attribute indexes for the current element, but it was actually slower for a single attribute access and wasn't really fast enough to justify the added complexity. Another option would be to include attributes much like elements in CMarkup indexing, but I think that's too fundamental at this point. So I've chosen to remain with the original reparse design for the time being, and hopefully the 11.3 performance boost and new method will help out enough.

If you have intensive use of attributes, in some cases you might want to extract them with GetNthAttrib to an external map as a more efficient machanism to access them repeatedly. You can even map them in a separate CMarkup object as elements using SavePos and then RestorePos to do the lookup.

See also:

video of XML splitter script
Format XML, indent align beautify clean up XML
Tree customization in the firstobject XML editor

See also:

video of XML splitter script
Format XML, indent align beautify clean up XML
Tree customization in the firstobject XML editor
firstobject Access Language
Counting XML tag names and values with foal
Convert ANSI file to Unicode

<?xml-stylesheet href="file.xsl" type="text/xsl"?>

If the XSL file is not specified, you must have both the XML and XSL documents open in the editor. When you invoke the Transform, you will be prompted with a list of open documents to select the other document. So if you press F9 from the XML document it will prompt you for the stylesheet, and if you press F9 from the stylesheet, it will prompt you for the XML to transform.

Like MSXML Validate Alt+F7, the Transform function uses the Windows MSXML component on your machine.

Those are just what has changed since intermediate release 2.3.5. A lot has happened since the last full release 2.3. Here are the interim releases:

MFC component improvements

Release 2.4 has many improvements since 2.3 in these source code classes:

See also:

Archived firstobject XML Editor 2.3 Release Notes
Archived firstobject XML Editor Release Notes

It became clear soon after CMarkup release 11.1 that another release would be needed to resolve a compiler issue affecting Visual C++, the _fseeki64 and_ftelli64 issue. From now on, some Visual C++ developers using file mode on files over 2GB will need to define MARKUP_HUGEFILE.

Here's the list of 11.2 enhancements:

• Cleaned up Visual C++ compiler _fseeki64 and_ftelli64 issue
• CMarkupMSXML: Added Transform method, just supply an XSL document "style sheet" (see MSXML Wrapper CMarkupMSXML)
• CMarkupMSXML: Implemented UTF-8 conversion for when MBCS (ANSI) strings are NOT being used

All the 11.2 developer version enhancements only affect file mode (see write mode and read mode).

• GetSubDoc in file read mode now uses smarter reallocations when extracting very large subdocuments. As CMarkup concatenates pieces of a subdocument spanning n read blocks, it won't realloc n times, more like Log(n)
• HUGE file support >2GB is no longer automatic in Visual Studio. For huge files in Visual C++ define MARKUP_HUGEFILE in your Project Settings Preprocessor definitions. To test whether you have huge file support make sure sizeof(MCD_INTFILEOFFSET) == 8 (see _fseeki64 and_ftelli64)
• fix: GetElemPath and GetParentElemPath in file mode
• fix: SetData in file write mode
• fix: OutOfElem in file write mode

See also previous CMarkup release notes: 11.1, 11.0, 10.1, 10.0, Archived CMarkup Release Notes