How to do a 'full save' with a COleDocument
rick cameron -- rick_cameron@msn.com
Wednesday, October 09, 1996
Environment: VC 4.2b on Windows 95 and NT; VC 1.52 on Windows 3
Our app is an Ole container, and we use the Ole compound file format to hold
our document files. In addition to the standard streams created by MFC and
Ole, we create various streams and storages in the file.
Some of our files can contain hundreds of streams. In others, individual
streams may be over a megabyte in size.
The normal MFC/Ole save procedure is as follows: the compound file is open in
transacted mode; serialization is done into streams in a temporary file
(managed by Ole); then upon Commit of the root storage, Ole copies the data
back into the base file.
With some of our documents this takes a very long time. It seems that the
Commit operation can be rather slow if there is a large number of streams to
be copied.
Another annoying effect of the standard method is that the size of the file
varies tremendously. This is, of course, due to the transacted nature of the
operation: at some point, the file contains both the old and the new version
of the data.
One idea we've had to improve this behaviour is to use the classic 'full save'
approach, as described in section 8.4.1 of the Ole 2 Specification. In this
approach, the document data is saved into a temporary file, the original file
is deleted, and the temporary file is renamed.
Sections 8.4 and 8.6 of the Ole 2 Specification discuss how a 'full save' can
be performed using the IPersistStorage and IStorage interfaces. However, it
appears to me that the approach described doesn't jibe very well with the way
MFC performs a File Save operation.
So, my questions:
1) Can anyone help figure out how to do a 'full save' under MFC?
2) Can anyone think of other methods that might alleviate the two problems
describe above?
With a promise of thanks, if help is given [is that acceptable, Ekim? ;^]
- rick cameron
Rajesh Paramasivan -- rajesh@viagrafix.com
Friday, October 11, 1996
Seems like if you open the root storage (and subsequent
streams and storages) in the DIRECT mode instead of the
TRANSACTED mode(as done by the MFC), all your problems will be
solved. So instead of letting the MFC create the root storage, you
can override the document's OnOpenDocument() function and create
the storage in DIRECT mode. For more info, check the
COleDocument::OnOpenDocument() function.
rick cameron wrote:
>
> Environment: VC 4.2b on Windows 95 and NT; VC 1.52 on Windows 3
>
> Our app is an Ole container, and we use the Ole compound file format to hold
> our document files. In addition to the standard streams created by MFC and
> Ole, we create various streams and storages in the file.
>
> Some of our files can contain hundreds of streams. In others, individual
> streams may be over a megabyte in size.
>
> The normal MFC/Ole save procedure is as follows: the compound file is open in
> transacted mode; serialization is done into streams in a temporary file
> (managed by Ole); then upon Commit of the root storage, Ole copies the data
> back into the base file.
>
> With some of our documents this takes a very long time. It seems that the
> Commit operation can be rather slow if there is a large number of streams to
> be copied.
>
> Another annoying effect of the standard method is that the size of the file
> varies tremendously. This is, of course, due to the transacted nature of the
> operation: at some point, the file contains both the old and the new version
> of the data.
>
> One idea we've had to improve this behaviour is to use the classic 'full save'
> approach, as described in section 8.4.1 of the Ole 2 Specification. In this
> approach, the document data is saved into a temporary file, the original file
> is deleted, and the temporary file is renamed.
>
> Sections 8.4 and 8.6 of the Ole 2 Specification discuss how a 'full save' can
> be performed using the IPersistStorage and IStorage interfaces. However, it
> appears to me that the approach described doesn't jibe very well with the way
> MFC performs a File Save operation.
>
> So, my questions:
>
> 1) Can anyone help figure out how to do a 'full save' under MFC?
> 2) Can anyone think of other methods that might alleviate the two problems
> describe above?
>
> With a promise of thanks, if help is given [is that acceptable, Ekim? ;^]
>
> - rick cameron
--
-----------------------------------------
Rajesh Paramasivan
rajesh@viagrafix.com
(918) 825-4844
| Вернуться в корень Архива
|