Webcentre Ltd FAQ

TCompress Frequently Asked Questions Last updated: September 2015 Contents: **** Purchasing and Licensing: * Do I need a per-copy runtime license to distribute applications which use TCompress? * What is the price to register and use TCompress? * Can I use it with C++ Builder, dotNet and Kylix 3 and Delphi compilers before XE3? * How much do I pay for multiple developer licences? * How quickly will a registration request be processed? * Can I also buy the source code if I want to? * Which source options do I need? * Do you take credit cards? * Do I need to make separate registrations for different compiler versions I own? * Can we pay with a check? **** Performance and Capabilities * How do I compile CompDemo or CompDB11 with XE7 or later? * Does TCompress create files compatible with ZIP, LHArc or Winzip? * Does TCompress require any external DLLs to operate? * Can I create a self-extracting EXE with TCompress? * Is TCompress "industrial strength", or does it have hidden size limitations or problems? * What is the Compctrl unit for? * Can I create archives which span across several disks? * How good is the data compression I get with TCompress? * I have some files which don't get any smaller when compressed using TCompress. Why not? * Why don't "protected" Paradox tables compress well with TCompress? * Is there a routine or component to auto-compress entire records within a database? * Is TCompress thread-safe? * Is TCompress Year-2000 compliant **** How To: * Can I seek into the middle of a compressed file and decompress just part of it? * Does TCompress handle updates and deletions from an archive nicely, or does it leave "holes"? * How do I use TCompress/TCDBMemo etc. if I have a Data Module in my project? * How can I speed up access to files in an archive? * How can I compress a string in memory? * How can I read string data and compress it into a blob field? **** Problems (also see the Troubleshooting section of Compress.hlp): * I compressed a file using TCompress, but I can't seem to decompress it. Why not? * I compressed something into a stream, but I can't seem to expand it. Why not? * How do I eliminate the registration popup message? Is any other functionality affected in an unregistered copy of TCompress? * My application says "Requires BDE" when I run it on another machine. Does TCompress require the Borland Database Engine? * What should I do if I get an "Out of Memory" message using TCompress? * Do you have any demo programs written specifically for C++ Builder, or are they all Pascal? * My application's memory use seems to increase every time I decompress files. Why? * What should I do if I see an "EUnableToCompress" exception? * How do I fix a "transliterate error" with TCDBMemo and Interbase blobs ============ And here are the answers: ================= **** Purchasing and Licensing: * Do I need a per-copy runtime license to distribute applications which use TCompress? No. You only need to buy a developers' license for each developer. * What is the price to register and use TCompress? See the pricing information and handy form in Registration section of the Compress.hlp help file which comes with TCompress. * Can I use it with C++ Builder, Delphi-DotNet and Kylix 3 and Delphi compilers before XE3? Yes, but we do not deliver trial object files for those compilers. Please test TCompress under Delphi using the trial DCUs we provide, then order a full-source licence to use with any of the above compiler. * How much do I pay for multiple developer licences? Please contact us if you want to buy a license for more than one developer; we offer generous discounts for multiple-license purchases. * How quickly will a registration request be processed? Fax or Email: Usually within the same working day. Mail: you should receive the registration codes and/or source code on disk within one week of our receipt of the order. * Can I also buy the source code if I want to? Yes. All the source of TCompress is available. You can buy the source code of the TCompress component itself (in the Compress unit), and separately buy the source of the blob field components (CDBMemo etc) in the Compctrl unit. * Which source options do I need? If you are just planning on working with compressed files (singly or in multi- file archives), you need the Compress unit source. If you will be using any of the blob compression components or classes, you should buy both the Compress unit AND the Compctrl unit source. * Do you take credit cards? Yes -- Mastercard, Visa and Amex only. * Do I need to make separate registrations for different compiler versions I own? No. One registration will cover one developer's use of TCompress with all of the compiler versions supported by the release of TCompress which is licensed. * Can we pay with a check? Yes. In general, we will accept most cheques in most currencies provided their value is a close match to the payment required. However, credit card orders can be processed more quickly. **** Performance and Capabilities * How do I compile CompDemo or CompDB11 with XE7 or later? You need to first install the BDE and its supporting units which is now provided separately by Embarcadero. For XE7 it is available at: http://cc.embarcadero.com/item/29997 * Does TCompress create files compatible with ZIP, LHArc or Winzip? No. TCompress uses compression methods which are comparable to those used in the above programs. However, in order to meet its design goals (in particular: general purpose compression capabilities, the ability to mix compression types in one archive, and support for "custom" compression), it does not use a file format compatible with any of the above. HOWEVER, our TCompLHA component is specifically designed to create and manage LHArc/LHA archives (which can also be used with WinZip). Naturally, TCompLHA can also read TCompress archives. For more information, see: http://www.webcentre.co.nz/compLHA.htm * Does TCompress require any external DLLs to operate? None whatsoever. TCompress is written in 100% native Delphi. * Can I create a self-extracting EXE with TCompress? Yes. In the Compress.zip file are two example projects that show how to do this -- selfextr.dpr and selfxsml.dpr. * Is TCompress "industrial strength", or does it have hidden size limitations or problems? Hundreds of developers are using TCompress for an extremely wide range of applications, with file sizes ranging from kilobytes up to tens of GB. They, and we, believe it to be a trouble-free solution for the range of compression problems for which it was designed. Limitations tend to be wholly a factor of the deployment platform (e.g. system resources, free disk space etc). Version 8.0 supports files and archives with an overall size bigger than the 2GB "OS-determined" limit which applied to earlier versions (there is a new upper limit, of course, but that is 8 exabytes = 2^63 bytes). * What is the Compctrl unit for? It contains all the classes and components for working with database Blob fields (CDBMemo, CDBImage, CDBRich, TCBlobfield, TCBlobstream etc). If you don't plan to work with any of those, you don't need to install it. * Can I create archives which span across several disks? Not with TCompress. Consider using our TCompLHA product, which includes a TSegLHA component -- see http://webcentre.co.nz/CompLHA.htm. * How good is the data compression I get with TCompress? All data compression is dependent on the method used and the nature of the input data. For best compression use the LZH5 algorithm -- its results should be similar to those you would get when using Zip compression with the same file(s). See the Introduction to Data Compression section of the Compress.hlp help file. * I have some files which don't get any smaller when compressed using TCompress. Why not? See the question above. Some files have data which is already so complex that they won't compress significantly, or at all. If you have coLZH5 set as your CompressionMethod, you should get roughly the same level of compression as common compression utilities will give you -- sometimes better. * Why don't "protected" Paradox tables compress well with TCompress? When you protect a Paradox table, the entropy or "randomness" of its data increases significantly -- so much so that all compression algorithms become much less efficient. You'll encounter this whether you use TCompress or any other common compression utility. * Is there a routine or component to auto-compress entire records within a database? No. TCompress provides file-level compression (e.g. the entire set of database files into a single archive) and TCDBMemo etc. provide blob-level compression (e.g. autocompressing memo, image or binary fields in your database). There isn't a way to compress entire database records and still provide the kind of fast indexed random access which most databases require. * Is TCompress thread-safe? Yes, the code can be used in multi-threaded applications. To use it effectively, you need to create an instance of the component within each new thread -- as per the example code in the CompDemo sample application. * Is TCompress Year-2000 compliant Yes. No date-based calculations are performed, and all date storage formats used are compliant with Windows definitions, which support four year digits. **** How To: * Can I seek into the middle of a compressed file and decompress just part of it? Generally speaking, no compression method will permit this. However, it can be "faked" in either of the following ways: 1. Decompress the entire file into a temporary TMemorystream, then use the TStream seek and read methods to access any part of it. This is not useful if the file is huge of course, but decompressing to a temporary TFilestream instead might be viable for some situations. 2. Instead of compressing it as a single file, compress it as a series of "chunks" or file segments, all stored in a multi-file archive (each chunk can be given a name in the archive which is its number, e.g. "1", "2" etc). With this approach you can randomly select any chunk and decompress it individually. For performance-critical applications, also see the question below on speeding up access to multi-file archives. * Does TCompress handle updates and deletions from an archive nicely, or does it leave "holes"? If the standard CompressFile(s)/DeleteFiles/ExpandFile(s) methods are used, archives are rewritten to eliminate holes and remove old files. You can bypass or delay this archive rewriting process if you want by using routines like CompressStreamToArchive. * How do I use TCompress/TCDBMemo etc. if I have a Data Module in my project? Put the TCompress object on your Data Module with your tables. Any CDBMemo etc. objects should still be on the appropriate form(s) of course. * How can I speed up access to files in an archive? For small archives, this is hardly necessary --- finding and decompressing any file is generally very fast. But if your archive gets very large, the sequential search needed to find a given file to decompress it can be a time- waster. A solution to this is to use ScanCompressedFile once when you first access your archive (as the Compdemo example application does). This process also creates a TCompressedFileInfo object for each file containing its position in the archive. With that information, you can open the archive as a TFileStream, seek directly to the appropriate place and use the DoExpand method to expand just that file. Time savings on large archives by using this method can be very significant indeed. * How can I compress a string in memory? Use the CompressString and ExpandString methods. * How can I read string data and compress it into a blob field? The simplest possible way is to use CompressString, then store that in the blob as binary data. However, this means you'll have to take care of the reading and expansion process yourself as well. A better way might be to use the visual CDBMemo component and simply use its LoadFromFile method to load the strings. If its compression properties are correctly set, it will auto-compress the data when the record is posted. If you want to do it non-visually (e.g. on a data module), do as follows: a) Create a non-visual TCBlobfield component on-the-fly and point it at your existing memo field (see BLOBMAIN.PAS for an example of this). b) Set its CompressSource and CompressionMethod properties appropriately c) Then step through each record of the table doing this: edit; OurBlobField.LoadFromFile(yourExternalFilename); post; { write back, forcing it to compress as it is written } Note that other handy assignment methods are available, including LoadFromStrings. If you want to compress existing uncompressed data in the memo, just assign the field to itself so that it is marked for updating, e.g. OurBlobField.asString := OurBlobField.AsString (good in Delphi 2 and 3 -- in Delphi 1 you'll have to SaveToStrings into a TStringList, then LoadFromStrings back again). **** Problems (also see the Troubleshooting section of Compress.hlp): * I compressed a file using TCompress, but I can't seem to decompress it. Why not? There are two likely reasons: 1. You have your parameters round the wrong way when calling the ExpandFile method. Sensible parameter naming will help you avoid this, e.g. ExpandFile(StoredFilename, ArchiveFilename). 2. You are not specifying the correct StoredFileName. It should match the filepath which is stored in the archive -- which can be double-checked by using the Compdemo program. Review the Compress.hlp help sections on TargetPath and "Filename Handling in Compressed Archives" to see some examples of how to control what filenames and paths are stored in the archive. * I compressed something into a stream, but I can't seem to expand it. Why not? Don't forget to either close and reopen the stream or (more commonly) seek back to the beginning of the stream before trying to expand from it! Also check that the stream FROM which you compressed the data had been positioned to the start before you compressed it. The Compress and Expand methods both work from the CURRENT stream location... * How do I eliminate the registration popup message? Is any other functionality affected in an unregistered copy of TCompress? When you register TCompress, you will be given values to set into the RegName and RegNumber properties of your TCompress components. If you set these exactly as provided to you, they will eliminate the popup. Apart from the popup message, unregistered copies of TCompress behave exactly the same as registered ones. * My application says "Requires BDE" when I run it on another machine. Does TCompress require the Borland Database Engine? No. If you are not using the database blob compression components (CDBMemo etc), then you don't need the BDE. Just be sure that your project units don't have any unintentional references to "DB" or "DBTables" etc. in their Uses clauses. Also make sure you have the "comp" package rather than the compdb package installed, as the latter "requires" the BDE package. * Do you have any demo programs written specifically for C++ Builder, or are they all Delphi? At this point, all the demonstrations are in Delphi but we've provided C++ compatible project header files so they can be checked under C++ Builder. * What should I do if I get an "Out of Memory" message using TCompress? This is exceptionally rare and will only arise if physical or swapfile memory is limited -- free up more disk space on your Windows swap drive. * My application's memory use seems to increase every time I decompress files. Why? If you are using the ScanCompressedFile or ScanCompressedStream methods, see the notes in their section of Compress.hlp about the TCompressedFileInfo information and the FreeFileList method, which will allow you to eliminate memory loss. * What should I do if I see an "EUnableToCompress" exception? Nothing, unless you are directly calling the DoCompress method (see the help). All other methods handle this exception internally, meaning that the only time you'll see this exception is if you have "Break On Exception" turned on in the IDE. * How do I fix a "transliterate error" with TCDBMemo and Interbase blobs This error is caused by the usual Interbase memo field SQL definition that sets the blob's data sub-type to "1", which can only be used for text. Consequently, the highly varied characters used in a compressed file are rejected. The fix is to amend your SQL to create a blob field with sub-type of zero, which is a binary blob, e.g. ALTER TABLE TEST_ONE ADD TEST_TEXT BLOB SUB_TYPE 0 SEGMENT SIZE 80; Thanks to Charlie Savage of Atkinson-Baker for this report.

Return to TCompress