> Mike: (or ?) can you give me some background why uncompress > works this way??
Are you asking why the table code has problems or why the uncompress function "cache" the uncompressed data on the storage heap? ;-) The only reason that the table code runs into problems is because that is how you implemented it ;-) You selected the simple solution and "reused" the compressed link record instead of adding a new record (or several) for the compressed table data. If you had asked me about my opinion before implementing this I would have adviced you to not reuse the link record and instead create a new solution for the table data... When I wrote the first version of the uncompress code (sometime in late 1999; only DOC compression at that time) my main concern was to use as little memory as possible while still make it fast (back in '99 the devices had at most 2MB of RAM and only a tiny amount of dynamic memory was available), so I used a small dynamic buffer to uncompress the data and wrote the uncompressed text data to one record in the storage heap and uncompressed image data to another record. Then the viewer works with the uncompressed data through a memory handle. The data in the "uncompress records" will be replaced whenever you access a new record/image. Anyway, if you need to keep track of several table records then I guess you could solve that by modifying the CreateUncompressBuffer and AllocateUncompressRecord functions (and add a new access function.) /Mike _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
