Leaderboard

It's called consistency and is considered to be a good thing...most of the time.

As a benefit I see better readability and flexibility. In case we decide to change TArray<T> to something like a TList<T> later, we only have to change that in one place. (Of course the code itself might have to change, too. But that has to be done anyway.) I often start with an alias like TItems = TList<T> and later extend that to TItems = class(TList<T>) with some additional or overridden functionality. Sometimes it is just to hide the necessary constructor parameters inside a simple TItems.Create. If the implementation is indeed relevant for understanding the code, I use type names like TItemArray and TItemList, even if those are also just aliases to TArray<TItem> and TList<TItem>. For me, these benefits are of much more value than keeping the namespace small. The latter may result in shorter compile times, which are already pretty short. Runtime performance and code maintainability gain near to nothing from it.

Be sure to have a backup, after installing this patch Reportbuilder and DevExpress Components connected with Teechart are not working any more: So, whats next if we don't have a backup ??

If it was true ... then we're definitely using Elphi 😉

@David Heffernan Which refactoring tool do you use that reliably will change some scenario where you have lots of places across lots of units where you had something like procedure SomeProc var myList:TList<TFoo> begin myList:=TList<TFoo>.Create then you want to change all places from TList<TFoo> to TObjectList<TFoo>. So the refactor would presumably change the variable declarations and the .Create calls across all the units. It really does not work reliably for us and we have lots of search..replace with invetiable 10 minutes of compiling churn to get it all right. We tend to do TFooList=TList<TFoo> and just use TFooList everywhere for this reason. If the refactoring tools worked well, it would make that less necessary.

Then you end up with different names for the same thing. How can that be better? Refactoring tools get these names changed very reliably. I don't understand why people are scared of changing names. If you aren't prepared to change names then your code will be a mess.

I've just run the patch, here a list of whats going on: Before install I had TChart and all Features I installed via welcome page this seems to be just a shortcut to the GeitManager Got the first message Yes, I want ... Then I've got a fullscreen terminal, which is odd. because I cannot see a hanging message-box request, it was behind the terminal. After pressing OK, it moved on Seems to de-install all features I've had installed before even Interbase and all SDK's ... Then its restarting the IDE Of course something is missing now, need attention later ... Then the features components 2nd page were all removed (as they were uninstalled), I had to enable them. Even the samples. Installing the components ... tea time ... Re-Installing also loads the TeeChart, I hope this is the new version then. I will see later in my tests. Finally after install Teechart is back I can compile Android, so also the SDK seems to be back, but I'm unsure if all Android-Components wer initialized. The welcome page still shows a patch, it seems to be an error in "patch installed" detection I re-enabled my TChart usage in a project, and compile the project for test. I found a few issues then: 1. The message box was hiding behind the full-screen terminal 2. All features were disabled and de-installed, even the samples. This is maybe for safety, but I think this could be optimized. 3. When IDE ist startin, to re-install, it noted about missing BPL Surely this could be optimized too, to set the IDE into a kind "installer mode" before, ignoring missing BPL. Then only show message after 2nd start, if still anything is missing. 4. Patch "installed" detection doesn't work reliably

Just for information, this is the readme file of that patch. I cannot see anything related to Teechart or the ability to load packages, but that may as well be hidden somehow. Also does the patch not include any binary that could be executed or loaded and do any harm. Note, that the patch do save the original files in %BDSCatalogRepository%\Backup. Patch1.txt Update: I just noticed that the mentioned patch is different to the one I was talking about. Will investigate further...

I can see also benefit in maintaining code. Imaging you change TItemArray = TArray<TItem>; to TItemArray = TArray<TItemEx>; In the TItemArray version you touch the code in one place only. In the TArray<TItemEx> version you touch the code in thousands of places maybe.

10.4 does not overwrite the 10.3 versions in C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ So, First install for 10.3, then install for 10.4 - and apply the fix above.

10.4 has an update to Bookmarks and Navigator. It creates C:\Program Files (x86)\Common Files\ParnassusShared and places ParnassusBookmarks_XSydney.dll ParnassusCoreEditor_XSydney.dll ParnassusNavigator_XSydney.dll So, to cure the 10.3 ailments, copy from C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ to the first mentioned common catalog Bookmarks-1.0\ParnassusBookmarks.dll to ParnassusBookmarks_XRio.dll ParnassusCoreEditor-1.0\ParnassusCoreEditor.dll to ParnassusCoreEditor_XRio.dll Navigator-1.0\ParnassusNavigator.dll to ParnassusNavigator_XRio.dll

I think you meant to write: TItems = TArray<TItem>; Apart from not having to type the angle brackets anymore this is exactly the same type as TItems is just an alias for TArray<TItem>

Have you tried TCamRemote from https://alkenius.no-ip.org/

The error is not in the implementation of the custom initializer. A custom initializer is available for the “TRec” type, but an initialization error is in the “TData” type, which does not have a custom initializer, but has a field of a managed type. In the code example, you can replace the custom initializer with any other custom management operator (finalizer, assign), and you will get the same error.

Codegen bug https://quality.embarcadero.com/browse/RSP-29299