DocumentContentChildDocuments Property

[DataMemberAttribute]
public List<ChildDocument> ChildDocuments { get; set; }

Property Value

For most common document formats the child documents (if any) will be fully populated. However, archives, media images, mail stores, and databases present a special problem. They can be very 'large' and to naively extract whole archives, media images, databases (binary table columns), or mail stores into memory would be impossible for 'large' files.

For archives (.7z,.zip, etc) and media image formats each ChildDocument in this list will not have properties FormatId and DocumentBytes set by a call to ExtractContent(String) but will have other properties populated. A separate call must made to get each child document's raw bytes (see ExtractItem(Int32, Stream, String) and ExtractSolidBlockItems(GetItemStreamCallback, ItemExtractionFinishedCallback, String)). Once the child item is extracted to a stream (MemoryStream or FileStream - up to user depending on byte size of item) then the child documents file format id (FormatId) can be determined by a call to OpenDiscoverSDK API.

For mail stores (.pst, .ost, .mbox, etc) the ChildDocuments property will not be set at all by a call to ExtractContent(String, Boolean, Int32). To get each child email document calls to GetNextMessage must be called until there are no more child email documents to be extracted (i.e., GetNextMessage returns null). Each child email document returned by a call to GetNextMessage will have its ChildDocument properties set including FormatId and DocumentBytes and will be added to this ChildDocuments list. Care must be taken to process (or save to disk) each email as its extracted and then set each email child document DocumentBytes property to null after extracting the email's content so that used program RAM memory does not grow too large.

Reference