Leaderboard

I'm glad to announce a new release of the HTML Office Library: 100% native and cross-platform Delphi library for conversion and displaying documents of the following types: Rich Text Format (RTF) MS Word 6-2007 binary format (DOC) MS Word XML document (DOCX) MS Power Point binary format (PPT) MS Power Point XML format (PPTX) MS Excel binary format (XLS) MS Excel XML format (XLSX) MS Excel XML binary format (XLSB) Adobe PDF format (PDF) Supercalc format (SXC) EPUB (electronic books). FB2 (electronic books). Markdown. Outlook Message (MSG) MIME message (.EML) Outlook databases (.OST, .PST) The Bat! database (.TBB) RAR archives ZIP archives Whats's new 1. Improved conversion quality for all document types. 2. Significantly improved conversion speed and memory consumption for all document types. 3. Reduced size of converted document for all document types. 4. Document to text conversion is now much faster (direct text extraction and use of SAX parser for XML). 5. Added support for MIME mail messages .EML (including attachments). 6. Classes for reading Outlook databases (.PST, .OST). 7. Classes for reading RAR archives. 8. Classes for reading The Bat message folders (.TBB). 9. New THtOfficeDocument.AsThumbnail function for creating document thumbnail. 10. Added support for password protected office files (OnPasswordRequest callback in converion methods) 11. New THtOfficeDocument.ConvertStreamtoText for converting to text with support for callback function which get next portion of text during conversion. 12. New MaxLines and MaxPages properties to limit size of converted document. 13. Converted Word/RTF documents can have paged and web layout. 14. Direct PDF export for all platforms (no OS or third party library used). 15. Fully functional text search engine (can index documents from any souce: file, archive, database, etc. using implementation of IHtVirtualFolder interface). Conversion speed measurements: There are two compiled demos available (source code of both applications is included): 1. Simple document viewer: allows to view any document on hard drive using file tree on left side and HtPanel on right. https://delphihtmlcomponents.com/FileBrowser.zip 2. Search Engine demo: create full text search index for documents located in selected folders and find any document from application or Web. https://delphihtmlcomponents.com/SearchEngine.zip This demo also shows the following features of THtSearchEngine: Date map - found document number by year Type Map - found documents by category Completion Test on sample database: Note that search time depends only on amout of found/shown documents and do not depend on total document count. https://delphihtmlcomponents.com/office.html

I'd watch the video... and rant about it afterwards 😉

I wrote a quick test app and then drilled down into some folders using the app and compared with the Mac's native "Finder" to look at a set of virtual machines. The Mac's Finder recognized the "Virtual Machines" entry as a folder and its file contents were the same list of virtual machines I can see in VMWare Fusion, each entry is a simple VM name, and the details pane shows when it was created, the bundle size, etc. My test app, using just the TDirectory and TPath classes, showed "Virtual Machines.localized" as a folder name and allowed me to drill into that folder and then again into one of the ".vmwarevm" files, listing all the .vmx, .vmdk, .plist, and other files that make up a virtual machine package. Same with the Applications folder: Finder shows the application icons whereas my app shows a ".app" extension for each entry which is a sub-folder that opens up the contents of the app giving me Info.plist, PkgInfo, etc. My conclusion is that your app will need to recognize the file extension or file type and handle it differently--or like @Remy Lebeau says, use the FileManager API directly.

There are two packages, ChromeTabs_R.dpk and ChromeTabs_D.dpk. The "_R" is the run-time only and supports both 32-bit and 64-bit. The _D package is the Delphi component and is the one that gets installed in Delphi and does not ship with applications. Delphi is 32-bit only so components also have to be 32-bit only. So if you compile both 32-bit and 64-bit platforms of ChromeTabs_R.dpk then install only the 32-bit platform ChromeTabs_D.dpk, you'll have 32-bit and 64-bit support for the components in your application. I just compiled and ran the 64-bit version of the demo that comes with the package so I know it works.

Law of Triviality. Every body's got an opinion about the bike shed but do we really need a video and an endless thread about it?

After you save the data to the file. Someone can edit the file or the original data in the database, thus the program should figure out how to merge back the data.

Yes, I know. Situation where we had two different memory models that required slightly different coding patterns was unbearable. When people belittle ARC as memory management model, they tend to miss the fact that the problem with full ARC memory management was not the ARC as memory management model, nor the compiler itself, but the existing code that was not coded according to ARC rules. Hence the whole DisposeOf nightmare we had. Also, every memory management mode has good sides and bad sides. Each model is better for some use cases and worse for other.

Try DelphiAST (link in my signature). Or you can try to find some pas-to-h converters (not sure they exist at all) which D should eat as well.

Interfaces give automatic memory management for the price of significantly complicated code navigation. They (in Delphi implementation) add more boilerplate for g/setter methods. Moreover, to avoid circled ownership they require weak refs which appeared only in 10.x

Your argument about intent is the closest that I have ever seen to a cogent argument on this subject. But I still don't buy it. In your argument, if you see code that sets references to nil then that indicates this "optional lifetime" pattern, for the sake of inventing a name. And your point is that if you set the reference to nil every time you destroy an instance, then you can't distinguish the optional lifetime pattern from the two more common lifetime patterns, let's call them "owned lifetime" where the object is destroyed in its owner's destructor, and "local variable lifetime" where the object is created and destroyed in a local method, and the reference is a local variable. The thing is though, when you see FAN in owned lifetime and local variable lifetime, it's unmistakeable what the lifetime is. You never think, oh, I wonder if this might be optional lifetime. That's why I don't buy the argument, and why I've never experienced the issues you describe. What I have experienced though is the pain of using a stale reference. That pain is eased if the reference is nil. And yes, we can use debug MM to write over memory when an object is destroyed, but I don't want that to happen in my release builds. And sometimes bugs only emerge in release builds.