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 :
- 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.) - comDoc_CreateDiscDocument(fileName$)
This function creates a new (empty) compound document on disc. All modifications are written directly to disc etc. - 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. - 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.
- Windows 2000 onwards only
- Simultaneous multiple access to individual documents is not possible.
Regards.