Remy Lebeau

Calling ReadBytes() with an AByteCount value greater than 0 will wait until the specified number of bytes have arrived in the InputBuffer. So, if you are expecting 7000 bytes then just call ReadBytes() 1 time with AByteCount set to 7000. But, if you don't know ahead of time how many bytes are coming, then you can call ReadBytes() with an AByteCount value less than 0 and it will return however many bytes are currently available in the InputBuffer (if it is empty, ReadBytes() will wait until any bytes arrive first). If you don't want to change your current logic, then you can simply catch the EIdReadTimeout exception and call ReadBytes() again with the AByteCount value set to the IOHandler's current InputBuffer.Size.

DLL_PROCESS_ATTACH should be in the same thread that calls LoadLibrary(), but DLL_PROCESS_DETACH is not guaranteed to be in that same thread. Raymond Chen even blogged about this issue back in 2009 (emphasis added by me): The thread that gets the DLL_PROCESS_DETACH notification is not necessarily the one that got the DLL_PROCESS_ATTACH notification

Actually, no. Creating and destroying windows is highly discouraged in DllEntryPoint(), see: Dynamic-Link Library Best Practices: Guess where the CreateWindow/Ex() and DestroyWindow() functions reside - in user32.dll ! 0x0EEDFADE is the exception code when a Delphi exception escapes into the C++ runtime. So, what exception type exactly is the TForm destructor actually throwing? My guess is EOSError if DestroyWindow() fails. But a TForm destruction does a lot of things, so there could be any number of reasons why it would fail while the DLL is in the process of being unloaded from memory. Perhaps, if your DLL's TApplication object were already destroyed (or in the process of being destroyed). You should run your code in the debugger and verify that. Your global Form1 variable would not be updated in that situation, so you would have a dangling pointer. One way to handle that would be to assign NULL to your variable in your Form's destructor. But really, this is not the kind of stuff that you should be doing in your DllEntryPoint() to begin with. It would be better to export a couple of functions from your DLL that the loading app can then call after loading the DLL and before unloading it.

The TMBCSEncoding constructor calls the Win32 GetCPInfo() API to query information about a specified codepage to initialize the TEncoding.MaxCharSize and TEncoding.IsSingleByte properties. The error means that the specified codepage is likely not installed on the PC. Unfortunately, the call stack and the error message do not indicate which codepage is failing. If you have the source code for IBX, have a look at which codepages the CreateEncodings() function is trying to initialize. Or, maybe the API Monitor can tell you which codepage is being passed to GetCPInfo().

You can't just "enable" C++20 in C++Builder's current compilers, as it is NOT IMPLEMENTED in any of them at all - except for the BCC64X preview compiler, in which case the page I linked you to earlier tells you how to "enable" it.

Or, more simply, just detect a function call involving an "array of const" argument preceded by a string argument, and then warn if the string argument is not a literal.

FYI, you can create and use a VCL TBitmap in a worker thread, you just have to lock the bitmap's Canvas to prevent the main thread from releasing the bitmap's GDI resources. The new TControl.RaiseOnNonMainThreadUsage property was introduced in 11.0 Alexandria: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/What's_New#Threading_safety_improvement However, it is currently only being used by the VCL when a TWinControl's window is created, not when it is accessed. Fortunately, there is a new TControl.CheckNonMainThreadUsage() method that is public, so you can call it for your own purposes before you access a UI control's members.

No, you cannot update the compiler. C++Builder simply does not support C++20 at this time, only up to C++17. Although, the BCC64X 64bit preview compiler does have partial support due to using Clang 15, whereas the other compilers in C++Builder do not as they are still using older Clang versions: https://stackoverflow.com/questions/77456540/does-cbuilder-12-0-support-c20-modules However, you can use the 3rd party {fmt} library, which implements many of C++20's formatting capabilities in pre-20 versions of C++: https://fmt.dev https://github.com/fmtlib/fmt

That is not a bug, but a feature of the Pascal language. More formally, inside a block ('begin..end' or 'repeat..until'), a semicolon is a statement separator, not a statement terminator, unlike with other languages. The last statement in a block is never terminated by a semicolon. If you write a semicolon, then the last statement will be an "empty" statement. Another quirk of Pascal requires a semicolon to be omitted when an 'if..else' is inside of a 'case of..else' to avoid ambiguity over which statement the 'else' belongs to: https://stackoverflow.com/questions/7574603/why-do-single-statement-blocks-require-not-using-semi-colons

What does the error message say, exactly?

True, though there is the Declarations and Statements (Delphi) documentation, which does state all declarations are terminated by a semicolon.

I asked Embarcadero about the error and they said this: So, "installing" the 12.2 Patch 1 from GetIt merely downloaded the installer, but did you actually run it? The build version should have been updated from 29.0.53571.9782 -> 29.0.53982.0329 if the patch was actually installed. They also said: The TParallelArray class constructor was added in the original 12.2 release, but was removed in the 12.2 inline patch. So, if your package is referring to the constructor after installing 12.3 then it was compiled with the un-patched build of 12.2.

CryptRetrieveTimeStamp simply does not exist on XP. If you have source code for FastReport then you will have to modify and recompile it to not use CryptRetrieveTimeStamp on XP. Or else contact the FastReport author for help.

Did you have all of the patches for 12.2 installed before you upgraded to 12.3? Patch 1 in particular dealt with package compatibility issues, so if you didn't have it installed then perhaps your packages are not compatible with 12.3.

No. 12.3 is a minor point update in the 12.x series, so you have to remove 12.2 when installing 12.3. Only different major versions can coexist.