Uwe Raabe

No problem. I like those easy to fix bugs

Actually I don't need new broken stuff at all - regardless of existing bugs being fixed or not.

Try again with CodeSite Logging switched off.

@Jacek Laskowski Finally I was able to write a proper test case that reliably produces an infinite loop with the old code. Although I am still unsure what steps have to be done to reach that, I resist to investigate this any longer - as long as the current code passes this test flawlessly.

@Jacek Laskowski and @ULIK Can you please try the new version 15.0.10.2369?

LoadAvailableInterfaces populates the Implements combobox at the bottom right of the property dialog. Using a property as the implementor of an interface is not that common.

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.