Uwe Raabe

Usually the Debug folder is inserted into the project search path at the beginning when you select "With Debug DCUs". The release folder stays in the search path as it comes from the library path for the selected platform. That way the files in the Debug folder take precedence over those in the Release folder. Only files not found in the Debug folder are taken from the Release folder.

Seems that a TCardPanel is better suited for your needs.

There is no decent number, but more votes may increase the probability for a fix to be included in a release. There is no guarantee, though.

If we can gather some more votes for that issue I will be happy to point the product management to it. As it seems to be some low hanging fruit (looks like a missing MoveViewToCursor call), we might have this being included in 10.4.1.

I knew I had heard of this before : Clicking in Search for Usages window doesn't scroll cursor into view

I am pretty sure, that is not the case here. There will probably be a one year time limit, but that is quite common for free licenses from Embarcadero. This would at least fill the gap until the CE will be available.

If I am not mistaken, Koru is referring to a different case: type IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; IFooBar = interface(IBar) ['{1A99C9D3-CC94-4BCE-BF9C-354BF14EC5C7}'] end; type TFooBar = class(TInterfacedObject, IFooBar) end; procedure Test; begin var FooBarObject := TFooBar.Create; Assert(Supports(FooBarObject, IFooBar)); Assert(Supports(FooBarObject, IBar)); //Fails! end; For me this is pretty logical, so nothing to be changed.

I am not sure if I can support this request. It is a simplification to avoid writing code, but it should be well thought before implementing it. There might be uses cases when this is unwanted and when it is done this way you may have a hard time to get rid of it again. Perhaps I can think about a use case for the current state.

Seems that LOCAL_NOUSEROVERRIDE is your friend here.

Instead of IMethod I would suggest a new directive interfaced, optional with an alternative name used with InterfaceOf (similar to a method resolution clause). type TProcessor = class public constructor Create; procedure ProcessData(var Data); interfaced; procedure CleanUp; interfaced(Clear); // InterfaceOf will publish this method as Clear procedure Clear; // used inside TProcessor property Value: Integer read GetValue; interfaced; // should work for properties, too end;

Not really. Besides only working inside the current unit, ist is merely a find and replace respecting some scope.

Thanks for the report. Added to the bug tracker.

Are you sure that the actual files are really removed or is it just that the components are simply not registered anymore? In my case the Manage Platform dialog shows German language unchecked while the IDE is still running in perfect German.

Blind guess: Could it be that we using a German RAD Studio is the cause?

I can confirm that the patch misses to install the previous selected languages, samples, help and so on. Especially TeeChart Standard is missing after installing the patch. I suggest to file a bug report.

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...

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.

Isn't that just a subset of Delphi?

I just wanted to point out that KSVC is probably dependent on the 10.4 release, but not the other way round. Will have a look at it later. Fortunately I was able to make my KSVC installation working with 10.4 myself.

<irony>Indeed! Why just didn't they defer the 10.4 release until yesterday when KSVC was ready. That would have made everyone happy, wouldn't it?</irony>

Support for Generics is still very basic in MMX, but improvements are on the TODO list. That said, use cases like yours are always very welcome.

You have to select all the fields to be converted in the MMX Code Explorer Window. For an example see this video: Convert Multiple Fields to Properties

It is not even specific to a query, but probably happens with all TStrings properties. I can even reproduce it with a plain TMemo editing its Lines property.

Not perfectly clean, but without those mentioned in your call stack.

I can reproduce it.