Uwe Raabe

That is a pretty long time for a rarely used feature (a property implementing an interface). I will see what can be done better here.

In case you give MMX Code Explorer a try: it has an Extract Interface refactoring. Given this class declaration type TMyClass = class private FNewProp: Integer; function GetNewProp: Integer; procedure SetNewProp(const Value: Integer); public procedure NewMethod; property NewProp: Integer read GetNewProp write SetNewProp; end; select the property and method in the members view of the MMX Code Explorer window and in the context menu select Refactorings - Extract Interface. In the following dialog enter the interface name, GUID etc. and you end up with this: IMyInterface = interface(IInterface) ['{8431B2B9-8D15-4308-BF08-26AB2BA4960F}'] function GetNewProp: Integer; procedure NewMethod; procedure SetNewProp(const Value: Integer); property NewProp: Integer read GetNewProp write SetNewProp; end;

@ULIK More than 16 seconds spent in LoadAvailableInterfaces. Does that roughly match the delay you see?

Damn, the build server intentionally removes the USE_CODESITE define for the Release, probably to avoid that slipping through. There is V15.0.9.2368 that should behave better. You don't need a complete CodeSite installation. I added a separate download for CodeSite Tools which are necessary if no CodeSite is installed. If anyone has doubts installing CodeSite Tools - just don't do it. You cannot have those logs then.

OK, will have a look...

There is a new beta release 15.0.8.2366 available. Besides some smaller fixes it has an option to produce some CodeSite log files to track down these freezing issues. Logging can be activated in the registry. For convenience I have attached a reg file that creates the necessary entries, but doesn't activate them: If the CSUseLogFile entry is set to 1, MMX creates a log file for each Delphi start in <My Documents>\My CodeSite Files\Logs with file name MMXLog_<timesptamp>.csl. When you encounter that freezing issue or performance drop while logging is active, just send me the corresponding log file. MMXDebug.reg

You should tick the lower checkbox and then select "System (erweitert)".

You know you can collapse not only single XMLDoc sections, but also all of them in one go?

The problem is, that RTTI doesn't provide the T in TSomeGenericClass<T> in the first place. This works for arrays because arrays have information about the element type in their RTTI. Of course there are workarounds to find out T for an TObjectList<T>, but looking at any code doing that: how would you declare some class type derived from TObjectList<T> without providing T? BTW, the helpers described in my blog posts do save a ton of scaffolding code. I was able to reduce a unit containing all the serialized classes from over 2000 lines downto less than 1200 lines. If only I were in charge of designing the relevant Delphi classes, you could bet on some significant improvements

Currently this will only work in Delphi 10.3.3 Rio thanks to implementing a code change I suggested in QP together with a couple of failing test cases (unfortunately only people with access to that beta are able to see it). I just have none, but after all I am not the Delphi compiler engineer.

@Lars Fosdal Serializing Objects with TJson and Serializing Generic Object Lists with TJson

The shown approach has some drawbacks, one being that it only works with aliases of TObjectList<T>, not for derived classes. While this was no problem in the my case, it bugged me a bit as I see classes derived from TObjectList<T> probably as a not so uncommon use case. Unfortunately the current implementation is a bit resistent against extensions, f.i. because methods are not virtual or instances are created directly instead of using some factory approach. Thus the possible solutions are a bit limited and not as developer friendly as expected. On the other hand, this may change in the future and if we can get an TObjectList<T> approach working now, it probably can be made more friendly in the future.

You can dispute it then.

I even found a simpler solution and am going to publish a blog post about that soon.

Not sure if this works for you, but at least it works for me with 10.3.3. Let's start with a TJSONInterceptor descendant for a generic TObjectList<T>. Note that <T> represents the type of a list item, not the type of the list itself. type TObjectListInterceptor<T: class> = class(TJSONInterceptor) public procedure AfterConstruction; override; function TypeObjectsConverter(Data: TObject): TListOfObjects; override; function TypeObjectsReverter(Data: TListOfObjects): TObject; override; end; procedure TObjectListInterceptor<T>.AfterConstruction; begin inherited; ObjectType := T; end; function TObjectListInterceptor<T>.TypeObjectsConverter(Data: TObject): TListOfObjects; var list: TObjectList<T>; I: Integer; begin list := TObjectList<T>(Data); SetLength(Result, list.Count); for I := 0 to list.Count - 1 do Result[I] := list[I]; end; function TObjectListInterceptor<T>.TypeObjectsReverter(Data: TListOfObjects): TObject; var list: TObjectList<T>; obj: TObject; begin list := TObjectList<T>.Create; for obj in Data do list.Add(T(obj)); Result := list; end; Now lets assume you have a list of TMyObject classes. So you need to declare these two aliases: type TMyObjectList = TObjectList<TMyObject>; { this one is actually not needed, just for readability } TMyObjectListInterceptor = TObjectListInterceptor<TMyObject>; Now we can declare a container class with a field of type TMyObjectList: type TMyClass = class private [JsonReflect(ctTypeObjects, rtTypeObjects, TMyObjectListInterceptor)] FContent: TMyObjectList; { this could as well be TObjectList<TMyObject> } FCount: Integer; FPage: Integer; FPageCount: Integer; public constructor Create; destructor Destroy; override; end; constructor TMyClass.Create; begin inherited Create; FContent := TMyObjectList.Create(); end; destructor TMyClass.Destroy; begin FContent.Free; inherited Destroy; end;

@Lars Fosdal Are you only producing JSON or do you also need the other way round (i.e. create a class instance from a JSON string)?

That may depend on the actual case. The Windows scaling is fine as long as you have images that look ok when enlarged significantly. Usually you have not. Also CAD like applications are not so good candidates.

You might be forced to reconsider this statement when your customers are more and more using high dpi configurations and criticize the visual quality of your application. While the IDE ist still not ready for prime time in 10.3.3, most of the applications can be tweaked to behave well in these situations. The upcoming 10.4 may be right better with that. Laying out this transition now may give you some advantage when demands are rising and management expects a quick fix (No, problem. You can have your Delphi update, but we have to deliver next week!).

Due to the sluggish behavior of the themed IDE in some of the later versions I decided to buy a new PC. It turned out that the overall power consumption of the new PC is lower than that of the previous one even with a significantly better performance.

Experience shows that this usually never happens - and if, it will not happen in the expected time frame, cost and functionality. The first barrier is usually the lack of documentation what the Delphi software does, how it does it and why it does it that way. I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

Unfortunately the problem is still present. The good thing is, that I now have the environment to investigate it. May take some time though...

Interestingly that was my first thought, too. Unfortunately I couldn't find any directory implementation described there.

I finally got hit by the problem myself and did some deeper investigation. It turned out that the freeze happens when System.pas was parsed in the background. It contains some constructs with conditional defines that are not handled well by the internal parser. Adding System to the list of excluded files avoids that. Then I made a complete scan over the available Delphi source files (at least those present on my development machine - alas, some platforms are missing) and found two other source files with the same problem: IdThreadSafe.pas and IdGlobal.pas. It would be great if those people affected by this problem can test this workaround and add System, IdGlobal and IdThreadSafe to the Excluded list.

It is still part of RAD Studio in Enterprise and Architect editions, but not in Community and Professional editions. Unfortunately there is no Add-On available anymore to extend a Professional edition. The only way is to upgrade to the Enterprise edition.

Just a note to your article TStringList vs. THashedStringList vs. TDictionary: In Delphi 10.3.3 THashedStringLIst is not used to speed up TMemInifile anymore. AFAIK it is not used anywhere in the standard libraries and probably only there to stay compatible. Btw, I agree that it is poorly implemented.