Leaderboard

Reading this thread, I've now decided that you all personally are the reason Rust exists.

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

MMX V15.1.1 is imminent. I hope the incorporated changes will handle even that scenario.

There is some code / interfaces in Macapi.foundation including one for NSFileManager, at least in Delphi 11.1. Used by TPath.InternalGetMACOSPath in System.IOUtils when {$IFDEF MACOS} which you can look at to get some ideas at least.

Change arg declaration to WParam: WPARAM; LParam: LPARAM;

Did you try to install it via GetIt? If so that try to clear the previous downloaded packages of Fastreport, then try to to install it again but running the IDE with administration rights (Run As Administrator).

The WParam of TMessage is ultimately of type NativeUInt while the WParam parameter is of type Longint. Since Delphi 11 the default Debug config has Range and Overflow checks enabled which causes any signed to unsigned or vice versa assignment to possibly raise a range check error. Strictly speaking any assignment of signed to unsigned and vice versa is a potential defect - you can reveal them by turning W1071 on with {$WARN IMPLICIT_INTEGER_CAST_LOSS ON}

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.

Unfortunately, I see nothing in Delphi that would allow you to use that flag in this situation. TDirectory.GetFiles() is just a wrapper for a typical SysUtils.FindFirst/Next() loop, so it handles whatever files and directories that loop would normally report. If a Package file is treated as if it were a directory (ie FindFirst/Next() returns TSearchRec.Attr with the faDirectory flag set), then TDirectory.GetFiles() is going to recurse into the Package's content if the SearchOption parameter is set to soAllDirectories (as it is in your example). Also, more importantly, FindFirst/Next() simply don't use the FileManager API to enumerate files, they use the POSIX opendir() and readdir_r() functions instead, which have no such skip-Package flag available. Unfortunately, the TDirectory.GetFiles() predicate is only called for files and not for directories (ie, only for items that do not have the faDirectory attribute). Which makes sense, since TDirectory.GetFiles() is looking for only files to add to its output array, so there is no point in it filtering out directories. To prevent TDirectory.GetFiles() from recursing into Packages automatically, you would have to call it with its SearchOption parameter set to soTopDirectoryOnly (which is its default value), and then manually call TDirectory.GetFiles() for any non-Package sub-directory you are interested in. Of course, TDirectory.GetFiles() won't report directories to you, so you would have to use a separate call to TDirectory.GetDirectories() (with SearchOption=soTopDirectoryOnly) and filter out the Packages as needed. Which means, your enumeration time is going to double from having to scan each directory twice. So, in this case, you will likely have to use the FileManager API directly, and not use TDirectory at all.

You forgot "no calling each other nazi" (see Godwin's law)

Since this is such sensitive debate, better set some base rules: no pulling hair no poking the eye no dropping hot coffee over the speaker desktop no high kick no low kick no wedgie let's try to keep this debate civilized

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.

I gave my reasons and arguments. I never said anyone has to agree with me. One thing is for sure. With ARC compiler that wouldn't have to care about compatibility with existing codebases there would be no Free nor FreeAndNil.

So, to wrap it up: Be a genius and have your decades old application rely on an object being available at all times. Or just double check to make sure. The penalty for that is being frowned upon by the real geniuses...or not.

This makes no sense at all. If you instead use Free and retain a stale reference to a destroyed object, then other code simply cannot know that the reference is stale. There are two main scenarios. Object destroyed by owner, either from another instance's destructor, or in a method with try finally lifetime. FAN is just a debugging guard against use after free. Or a reference to an instance whose lifetime is dynamic. Perhaps created and destroyed multiple times by its owner. Then nil is used to indicate the state that the object is currently not in existence. It seems bizarre to me that anybody could advocate carrying around stale pointers.

Hm, wasn't the point of the first post in this thread that FreeAndNil isn't big enough of a subject to make a whole video about? Two pages of discussion say otherwise.

As you say, that's a problem with the developer rather than the function itself. I personally use FAN everywhere and my debug builds use FastMM with all bells and whistles. There aren't downsides to using FAN and it does make it easier to catch some defects.

You fix the bug, which is nothing to do with FAN. That's my point.

No it doesn't. How else are you going to allow constructors to raise exceptions?

At night in the cemetery, a dwarf bounces in front of the humpy and asks: - What's on your back? - A hump. - Do you need it? - No. - Then I'll take it. The humpy suddenly straightens, happily seeing that he is no longer crippled. He hurries home and meets the lame and tells what happened to him. The lame immediately rushes to the cemetery, searching for the dwarf. The dwarf jumps in front of him and asks: - What's on your back, lame? - Nothing... - Then get it, here's a hump!

Yeah, because delphi is so fast! But also, I doubt you could find a real program that would have a measurable performance hit even if the ref was set to nil always.

I don't care, sorry.

There are some other zip implementations in my awesome list. I'm happy with FWZip, however I only needed very basic actions

Posting French message on an English section of German forum is weird