PureBasic Forum

comDoc 1.3 - 23nd Apr 2010.

Version 1.3 fixes a \ReadString() problem (Unicode destroyed it!)

===================================


comDoc 1.2 - 22nd Apr 2010.

Version 1.2 fixes a memory leak.

===================================


comDoc 1.1 - 22nd Apr 2010.

Version 1.1 comes with the following changes :

• Added a \FileSeek() method (doh! I can't believe I forgot this!)
• Renamed comDoc_CreateDocument() to comDoc_CreateDiscDocument()
• Renamed comDoc_OpenDocument() to comDoc_OpenDiscDocument()

On top of this there are now 4 functions for use in creating a compound document as follows :

1. comDoc_CatchDocument(memoryAddress, size)
   This function will load a previously created compound document embedded within some memory buffer or other. All modifications are written directly to memory. (The original buffer is left intact even if you modify the subsequent document object. Simply save the modified document to disc if you require a permanent copy. N.B. you can free the original buffer at any time.)
2. comDoc_CreateDiscDocument(fileName$)
   This function creates a new (empty) compound document on disc. All modifications are written directly to disc etc.
3. comDoc_CreateMemoryDocument()
   This function creates a new (empty) compound document in memory. All modifications are written to memory. Simply save the modified document to disc if you require a permanent copy.
4. comDoc_OpenDiscDocument(fileName$)
   This function will load a previously created compound document from disc. All modifications are written directly to disc etc.

It is worth noting that the \SaveDocumentAs() method can only save to disc. It cannot save to a memory buffer. I do not, at this time, intend adding a facility for saving compound documents to memory as I see little need for this in light of the fact that you can load documents from memory (or create new ones in memory) and all modifications are then written back to memory anyhow. Why would we require a second copy of the same compound document in memory? You can save memory based compound documents to disc at any time.

See the nxSoftware site for the download.

===================================


Hi,

here is a small utility which I have called comDoc which wraps some of the Windows Compound File COM api (structured storage).

comDoc allows applications to create proprietary documents which act like an entire file system in that a single document can contain any number of disparate 'files'. Each such document itself occupies just a single disk file (regardless of how many 'files' it contains!)

For example, imagine a word processing application. Such an application may wish to save not just the text entered by the user within it's documents, but it may also need to save images, charts, spreadsheets and so on within the same document and in such a way that each separate image or chart etc. can easily be retrieved and altered etc. This is exactly what comDoc facilitates.

Features...

• x86 and x64 compatible
• Unicode compatible
• Simple to use OOP api
• Create new 'files' in individual documents
• Delete files from individual documents
• Enumerate all items in a compound document
• An extensive list of methods for working with individual files (ReadByte(), ReadWord(), ... WriteByte(),... WriteString()... etc.)
• Batched error reporting. Saves checking for errors after each individual write operation etc.

Restrictions...

• Windows 2000 onwards only
• Simultaneous multiple access to individual documents is not possible.

Please see the nxSoftware site for the download etc.

Regards.

Thank you nicely, very interesting code

You're welcome Thomas.

Feature Request!

Is there a way to add a methode like:

It's useful for packed or crypted Files.

I am not sure I understand what you mean exactly? I can attach at least 3 meanings to your question Thomas and so you will need to be more specific.

Are you wishing to create a document object based upon a memory buffer rather than a disk file? If so then I think this is possible via a suitable ILockBytes interface pointer.

Or are you asking that in cases where you have a document object open (disk based) that you would like to add a file object directly from memory?

I will pack or crypt the document. So i load the packed file, unpack in memory and then using with
your lib, without saving the unpacked one.

Right, then you are basically asking for a comDoc_CatchDocument(*memoryAddress, size) type function (not a method) to complement comDoc_CreateDocument(fileName$) and comDoc_OpenDocument(fileName$) right?

If so, then yes I think it is possible through an ILockBytes interface. I shall have a crack at it tomorrow.

A good feature request... I can't believe I didn't consider it! Doh!

yes is right. thank you

comDoc 1.1 - 22nd Apr 2010.

Version 1.1 comes with the following changes :

• Added a \FileSeek() method (doh! I can't believe I forgot this!)
• Renamed comDoc_CreateDocument() to comDoc_CreateDiscDocument()
• Renamed comDoc_OpenDocument() to comDoc_OpenDiscDocument()

On top of this there are now 4 functions for use in creating a compound document as follows :

1. comDoc_CatchDocument(memoryAddress, size)
   This function will load a previously created compound document embedded within some memory buffer or other. All modifications are written directly to memory. (The original buffer is left intact even if you modify the subsequent document object. Simply save the modified document to disc if you require a permanent copy. N.B. you can free the original buffer at any time.)
2. comDoc_CreateDiscDocument(fileName$)
   This function creates a new (empty) compound document on disc. All modifications are written directly to disc etc.
3. comDoc_CreateMemoryDocument()
   This function creates a new (empty) compound document in memory. All modifications are written to memory. Simply save the modified document to disc if you require a permanent copy.
4. comDoc_OpenDiscDocument(fileName$)
   This function will load a previously created compound document from disc. All modifications are written directly to disc etc.

It is worth noting that the \SaveDocumentAs() method can only save to disc. It cannot save to a memory buffer. I do not, at this time, intend adding a facility for saving compound documents to memory as I see little need for this in light of the fact that you can load documents from memory (or create new ones in memory) and all modifications are then written back to memory anyhow. Why would we require a second copy of the same compound document in memory? You can save memory based compound documents to disc at any time.

See the nxSoftware site for the download.

Following the release of version 1.1 of comDoc, a tip...

Loading a compound document from disc (or creating a new disc based document) results in a document which you can read/write to and all modifications are immediately written back to the disc file. If you would prefer to have the compound document reside entirely in memory whilst you work with it (and have all modifications written to memory as opposed to disc) then follow the steps listed :

1. Load the compound document into a memory buffer using PB's memory and file commands.
2. Use the newly added comDoc_CatchDocument() function to create a memory based document object from the memory buffer created in step 1.
3. Free the temporary buffer created in step 1.

And that's it.

If you later need to save the document back to disc then simply use the \SaveDocumentAs() method etc.

thx, i love it!

Thanks. I must admit that this is going to be bloody useful!

thanks srod very simple and good.
I love your programming and jobs.

thanks again.

indeed, i have a lot of programs which needed it, thanks a lot

@srod

When you say "any number of disparate 'files' " - do you mean documents only or files of any type?

Looks good and I can see the your touch of excellance in this product, thank you very much