RICHED20.DLL problem to display large RichText files using STREAMI

From:

=?Utf-8?B?d2VybmVyIG0uLi4=?= <wernerm@discussions.microsoft.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Tue, 22 Jul 2008 04:21:00 -0700

Message-ID:

<D8259B93-7AF9-4205-A704-BED207FD2FF5@microsoft.com>

I'm using CRichEditDoc / CRichEditView classes for displaying very large RTF
files. Normally for small files everything works fine. But for example, my
TEST.RTF file has a size of 134.679 KB than it will take about - 1 HOUR - to
streamin the text into the view window. The reason for that long time is,
that RICHED20.DLL supplies the EDITSTREAMCALLBACK function by a default
buffer size of only 4,096 bytes. Now I have changed in the CArchive
parameters the buffer size to a larger amount ( 65535 bytes ) and also set
an optional pointer to a user-supplied buffer of this size. But the
EDITSTREAMCALLBACK function is still supplied by the internal default buffer
with a size of 4096 bytes ( 4092 ).

/*==================================================
  OnOpenDocument ( CRichEditDoc )
===================================================*/
BOOL CLianTrp::OnOpenDocument( LPCTSTR lpszPathName )
{
int iBufSize = 65535;
LPBYTE lpBuffer = NULL;
.......
  lpBuffer = new BYTE[iBufSize];
  ( *lpBuffer ) = 0;
  CArchive archiveTrp( pFile, CArchive::load|CArchive::bNoFlushOnDelete,
iBufSize, lpBuffer );

  archiveTrp.m_pDocument = this;
  archiveTrp.SetLoadParams( 8192 );

  ulLength = pFile->GetLength();
  if( ulLength != 0 )
   { sLine.Format( _T(TEXT_ARC_PROGRESS_4), ulLength );
     m_pProgress->SetStatus( (LPCTSTR) sLine );
     m_pProgress->SetRange ( 0L, ulLength );
     m_pProgress->SetPos ( 0L );
     Serialize( archiveTrp ); }

  archiveTrp.Close();
  ReleaseFile( pFile, FALSE );
  delete m_pProgress;

  if( lpBuffer != NULL )
   { delete[] lpBuffer;
     lpBuffer = (LPBYTE) NULL; }
.......
return( TRUE );
}

/*==================================================
  Serialize ( CRichEditDoc )
  Message is sent to RICHED20.DLL ! All the parameter seems to be fine.
===================================================*/
void CLianTrp::Serialize( CArchive& ar )
{
long lResult = 0;
EDITSTREAM es = { 0, 0, CViewTrp::LoadStreamCallBack };
_afxRichEditCookie cookie( ar );
  cookie.m_pProgress = m_pProgress;
  es.dwCookie = (DWORD_PTR) &cookie;

  if( ar.IsStoring() )
   { }
  else
   { // Loading --> Message goes to RICHED20.DLL
      lResult = ::SendMessage( (HWND) GetView()->m_hWnd, EM_STREAMIN,
(WPARAM) SF_RTF , (LPARAM) &es ); }

  if( cookie.m_dwError != 0 )
   { AfxThrowFileException( cookie.m_dwError ); }
}

/*==================================================
  LoadStreamCallBack ( CRichEditView )
  Call comes from RICHED20.DLL ! Parameter "pbBuff" and "cb" are wrong.
==================================================*/
DWORD CALLBACK CViewTrp::LoadStreamCallBack( DWORD_PTR dwCookie, LPBYTE
pbBuff, LONG cb, LONG *pcb )
{
DWORD dw = 0;
_afxRichEditCookie* pCookie = (_afxRichEditCookie*) dwCookie;
CProgressDlg* pProgress = pCookie->m_pProgress;
CArchive& ar = pCookie->m_ar;

  ar.Flush();
  TRY
   { *pcb = ar.GetFile()->Read( pbBuff, cb );
     pCookie->m_ulCounter += *pcb;
     pProgress->SetPos( pCookie->m_ulCounter );
   }
  CATCH(CFileException, e)
   { *pcb = 0;
     pCookie->m_dwError = (DWORD)e->m_cause;
     dw = 1;
     e->Delete();
   }
  AND_CATCH_ALL(e)
   { *pcb = 0;
     pCookie->m_dwError = (DWORD)CFileException::genericException;
     dw = 1;
     e->Delete();
   }
  END_CATCH_ALL

  if( pProgress->CheckCancelButton() == TRUE )
   { // User break
     dw = 1; }

return( dw );
}

Following is documented in the MSDN Library :

Constructs a CArchive object and specifies whether it will be used for
loading or storing objects.

CArchive(
   CFile* pFile,
   UINT nMode,
   int nBufSize = 4096,
   void* lpBuf = NULL
);
.......
nBufSize
An integer that specifies the size of the internal file buffer, in bytes.
Note that the default buffer size is 4,096 bytes. If you routinely archive
large objects, you will improve performance if you use a larger buffer size
that is a multiple of the file buffer size.

lpBuf
An optional pointer to a user-supplied buffer of size nBufSize. If you do
not specify this parameter, the archive allocates a buffer from the local
heap and frees it when the object is destroyed. The archive does not free a
user-supplied buffer.
.......

Can anybody tell me why it does not work or has anybody the soure code of
the DLL file ( riched20.dll ) so I can find out the problem ???

Thanks !