Leaderboard

This treats TPassword like a string yet in Berlin+ you can add a unique Record Helper for TPassword. TPassword = type string; // Example of a Helper for TPassword TPasswordHelper = record helper for TPassword function CheckPwdComplexity(const MinPwdLen: Word; const Level: TPwdComplexity): boolean; function ContainsLower(const Required : Cardinal = 1): boolean; function ContainsSpecial(const Required : Cardinal = 1): boolean; function ContainsUpper(const Required : Cardinal = 1): boolean; function Secure(const ProtectWith: TSecureStringProtection = ssFast): ISecureString; function BCrypt: TBCrypt; inline; end;

How about fixing the issues that FastMM4 has rather than inventing yet another newly mostly untested and unproven memory manager?

For any project that is bigger than 200 lines (and allows non-stock dependencies) I use full version.

Cross-platform, the only way is to perform an I/O operation on the socket and check for error. On Windows, at least, a non-blocking socket can issue an asynchronous FD_CLOSE notification when the connection is closed, but you should still check I/O operations for errors, too. The same type of coding will work on POSIX, too. The base BSD socket API, like select() and recv(), is common across multiple platforms. Why are you passing your fd_set variable as the buffer for recv() to read into? More importantly, you can't pass -1 as the size of the buffer to read into. On Windows, the len parameter is an int, so it will at least compile with a length of -1, but semantically asking recv() to read -1 number of bytes makes no sense, and is not documented as a supported operation. But worse, on other platforms, the len parameter is a size_t, which is an unsigned type, so passing in a length of -1 will wrap to a very large value and very bad things can happen! Also, you are not checking to make sure that select() actually reports the socket is readable before then calling recv() on the socket. Since you are only querying 1 socket, the return value of select() will be -1 on error, 0 on timeout (not readable), and 1 (readable). Alternatively, since select() modifies the fd_set struct on output, you can check if your socket is still in the set after select() exits. Also, you are not handling recv() reporting an error at all. Either way, do keep in mind that you are performing an actual read, so any bytes that recv() does actually receive will not be available for subsequent reads, so you will have to buffer the bytes somewhere in memory so you can still use them later. In most cases, implementing an IsConnected() type of function is really unnecessary and should be avoided.

Yes. Everyone's situations are different, requiring different FastMM configurations, and most of those settings can't be set dynamically at runtime. So it makes sense for Embarcadero to ship with a minimal configuration and let people upgrade to the full version if they need to customize the settings. Yes, but not everyone uses the same configuration. Full

Yes, exactly. We're going to be dropping support for old compilers, Delphi and FreePascal alike, which do not support UnicodeString (we are not going to handle WideString). Providing backwards compatibility for AnsiString when Unicode is now part of most modern network protocols, as well as modren RTLs being Unicode-based, has made a real mess of the codebase. We are also dropping support for .NET completely. Indy 11 is intended to be a maintenance release to do some much-needed cleanup.

It is probably related to this code in System.Classes.ThreadProc: try Thread.Execute; except Thread.FFatalException := AcquireExceptionObject; end; You should be able to get any exception in the threads OnTerminate handler reading its FatalException property. See also http://docwiki.embarcadero.com/Libraries/Rio/en/System.Classes.TThread.FatalException

Official one - shipped one does not have the ability to report the exact allocation callstacks or detect use after free. It's nice to see *that* you have a memory leak with the shipped one but not knowing where exactly it comes from (unless the class name gives a direct hint) is pretty useless.

That is because Indy doesn't use batch files anymore for newer Delphi versions (it does for C++Builder, though). You can simply open the 5 DPKs in the Delphi IDE and compile and install them directly. UInt8 (and other (U)IntX data types) are defined for Delphi 2007 and earlier in the IdGlobal.pas unit, which IdBuffer.pas uses. Indy's IdCompilerDefines.inc file defines HAS_UInt8 for Delphi 2009 and later. IdGlobal.pas declares UInt8 when HAS_UInt8 is not defined. So there is no reason for IdBuffer.pas to not know what UInt8 is, whether it comes from Indy's IdGlobal unit or the RTL's System unit. My guess is that you probably have multiple versions of Indy's source code on your computer, and IdBuffer.pas is finding an older version of IdGlobal that does not implement UInt8 for Delphi 2007. Yes. At least until Indy 11 is released (no ETA on that at this time), which will drop support for Delphi 2007 and earlier going forward. Because there isn't one.

There is one loophole in your design: if a form is destroyed it will not automatically set the form variable the designer created for it to nil. I can only stress what has been posted in some of the other replies: do not use the form variables for forms that are not autocreated! Delete the variable declaration directly after the form unit has been created by the designer. Use local variables for modal forms (or a class method to create, use, and destroy them). For modeless forms you can always find existing instances by looking at the Screen.Forms array, or have the main form (which presumably creates such a form on an as needed basis) keep the reference in a private field. The automatic form variables encourage some bad programming practices (like accessing controls on another form directly) and become worse than useless if you have to have more than one instance of a given form class open at the same time.