/**
* @param shouldIncludeContinueRecords caller can pass <c>false</c> if loose
* {@link ContinueRecord}s should be skipped (this is sometimes useful in event based
* processing).
*/
public RecordFactoryInputStream(Stream in1, bool shouldIncludeContinueRecords)
{
RecordInputStream rs = new RecordInputStream(in1);
List <Record> records = new List <Record>();
StreamEncryptionInfo sei = new StreamEncryptionInfo(rs, records);
if (sei.HasEncryption)
{
rs = sei.CreateDecryptingStream(in1);
}
else
{
// typical case - non-encrypted stream
}
if (records.Count != 0)
{
_unreadRecordBuffer = new Record[records.Count];
_unreadRecordBuffer = records.ToArray();
_unreadRecordIndex = 0;
}
_recStream = rs;
_shouldIncludeContinueRecords = shouldIncludeContinueRecords;
_lastRecord = sei.LastRecord;
/*
* How to recognise end of stream?
* In the best case, the underlying input stream (in) ends just after the last EOF record
* Usually however, the stream is pAdded with an arbitrary byte count. Excel and most apps
* reliably use zeros for pAdding and if this were always the case, this code could just
* skip all the (zero sized) records with sid==0. However, bug 46987 Shows a file with
* non-zero pAdding that is read OK by Excel (Excel also fixes the pAdding).
*
* So to properly detect the workbook end of stream, this code has to identify the last
* EOF record. This is not so easy because the worbook bof+eof pair do not bracket the
* whole stream. The worksheets follow the workbook, but it is not easy to tell how many
* sheet sub-streams should be present. Hence we are looking for an EOF record that is not
* immediately followed by a BOF record. One extra complication is that bof+eof sub-
* streams can be nested within worksheet streams and it's not clear in these cases what
* record might follow any EOF record. So we also need to keep track of the bof/eof
* nesting level.
*/
_bofDepth = sei.HasBOFRecord ? 1 : 0;
_lastRecordWasEOFLevelZero = false;
}
/**
* @param shouldIncludeContinueRecords caller can pass <code>false</code> if loose
* {@link ContinueRecord}s should be skipped (this is sometimes useful in event based
* processing).
*/
public RecordFactoryInputStream(Stream in1, bool shouldIncludeContinueRecords)
{
RecordInputStream rs = new RecordInputStream(in1);
List<Record> records = new List<Record>();
StreamEncryptionInfo sei = new StreamEncryptionInfo(rs, records);
if (sei.HasEncryption)
{
rs = sei.CreateDecryptingStream(in1);
}
else
{
// typical case - non-encrypted stream
}
if (records.Count != 0)
{
_unreadRecordBuffer = new Record[records.Count];
_unreadRecordBuffer = records.ToArray();
_unreadRecordIndex = 0;
}
_recStream = rs;
_shouldIncludeContinueRecords = shouldIncludeContinueRecords;
_lastRecord = sei.LastRecord;
/*
* How to recognise end of stream?
* In the best case, the underlying input stream (in) ends just after the last EOF record
* Usually however, the stream is pAdded with an arbitrary byte count. Excel and most apps
* reliably use zeros for pAdding and if this were always the case, this code could just
* skip all the (zero sized) records with sid==0. However, bug 46987 Shows a file with
* non-zero pAdding that is read OK by Excel (Excel also fixes the pAdding).
*
* So to properly detect the workbook end of stream, this code has to identify the last
* EOF record. This is not so easy because the worbook bof+eof pair do not bracket the
* whole stream. The worksheets follow the workbook, but it is not easy to tell how many
* sheet sub-streams should be present. Hence we are looking for an EOF record that is not
* immediately followed by a BOF record. One extra complication is that bof+eof sub-
* streams can be nested within worksheet streams and it's not clear in these cases what
* record might follow any EOF record. So we also need to keep track of the bof/eof
* nesting level.
*/
_bofDepth = sei.HasBOFRecord ? 1 : 0;
_lastRecordWasEOFLevelZero = false;
}
