Leaderboard

Well, 3rd party DLLs are not scary - OpenSSL, DB clients, chromium, etc. Sometimes they distribute the product as DLL so that any language could use it, even brainfuck. However there are plenty of native Delphi network components, commercial or free. I wouldn't use DLL for this without a significant reason. And if I would it would likely be cURL

I agree with Magno: KASTRI works like a charm out of the box! I was able to implement the sharing of a PDF file on Android in 30 minutes...

You may want to give pyscripter/Ssh-Pascal: Delphi ssh library wrapping libssh2 (github.com) a try. It is a wrapper around libssh2, includes scp, sftp, ssh support. Very fast.

I think we have beat this horse enough. I have two solutions that will work, and I have my beta testers evaluating each to determine which way we are going to go. Many thanks to everyone who provide input.

One of my current clients has been using ChilKat for FTP & SFTP for years and it seems to work fine. The first thing I did in order to work with it was write a set of wrapper classes that hide the ugly DLL API and abstract the FTP and SFTP differences away. I'd have preferred something with source code though, but AFAIK there's nothing for Delphi and the choice had already been made.

One of the major reasons to use components from Chilkat was SFTP and/or FTPS in contrary to Indy, a few years ago. Without a real good reasons, performance concerning floating point operations for example, I'm no big fan of deploying dynamic link libraries instead of static linking. What's missing Embarcadero has to provide and improvements too. Where does deploying this and that a different way lead? It does cause headaches even on a mid term in practice. Headaches go away with a Delphi only solution after while and then problems 'Wolpertinger' style deployments start. The whole story looks different if you want one homogenous component set serving different development technologies and/or programming languages. Even in this case homebrew, (bindings) provided by a community and/or out of the box come into play. Thinking of Java with the possibility to 'just plug-in' a different socket would be an alternative (early days of SSL). After a while what makes the difference today will be caught up by a certain kind of 'out of the box' way of doing things.

Use TThread.ForceQueue from inside the OnShow handler. TThread.ForceQueue accepts an optional delay.

I met that site a couple of times but it never managed to gain my trust for the exact reason you mentioned - a compiled DLL is an extremely unusual way to distribute your code and can do things in the background what you don’t want. “Don’t fix something which ain’t broke” applies here as well. Don’t purchase something and start to adapt all your code for it if they are working without issues.

No that's the limitation of the Delphi. It doesn't support exceptions during initialization of the application. The same problem has Skia if the dll is missing (of course in case of skia there is an easy fix replace the exception with showmessage).