Stefan Glienke

RemoveAll is the way to go - it is optimized internally for lists (at least since 2.0/develop) - not yet for dictionaries but there it more depends on what is the criteria for deleting items as remove by key is already O(1) The approach with Where/Remove does not work because the result of Where is lazy evaluated and will raise an exception once the source gets modified (after the first deleted item). Even when calling ToArray to manifest the collection of to removed items the Remove will be a waste of time because items would be searched all over.

Measure, don't guess - basic rule of performance tuning Linked list is a bad idea btw - if anyone thinks otherwise he needs to get an update on modern CPU architectures.

GetKeyState and related WinAPI functions are broken with Numlock enabled - and you are not the only one suffering from this defect if you google for numpad shift stuck If you release the shift key first it never sees the keyup of the insert key (which the shift key turned the numpad 0 key to). You have to use other ways to do that

Use diff tool/setting that also shows whitespace/eol differences

If there are no generics it's a different issue than RSP-27000.

The reason is they added a converter for encoding fields in TStrings to Data.DBXJSONReflect so it writes it different from before.

I just tested it and reduced the code further to pinpoint the wrong behavior, added additional information and reported as RSP-27000

Emba does not contribute to open source - especially not GPL

The TypeInfo uses the value $80000000 to indicate that this property has no default value. That unfortunately overlaps with Low(Integer). You have to use the stored keyword: property MinValue: Integer read FMinValue write SetMinValue stored IsMinValueStored; function TMyComponent.IsMinValueStored: Boolean; begin Result := FMinValue <> Low(Integer) end;

Because!

The point is that DestroyWnd is never called on the TForm (tested with 10.3) thus FDropTarget never destroyed.

It ever did? Not for code that I write and it does not completely format as I would like it to.

Nah, in fact I only use a fraction of what GExperts offers, I just cba to disable those that I don't need.

Use LeakCheck - there is even a blog post how to. Not having done anything on something that just works does not mean abandoned. If something does not work, let him know. FastMM is good to report memory leaks on an entire application run but not suited for unit tests memleak reporting - that is why LeakCheck was written plus having something that works cross platform.

Although I am a big fan of rtti and attributes I would choose the const array[enum] of x any day as its compact to write and compile time evaluated (i.e. error if someone introduces a new enum value and forgets to specify an array value for it).

Check the $RTTI directive in System.pas ... - also there is no this or that RTTI. Stuff from Rtti.pas just puts an easier to use layer ontop of the pointer stuff from typInfo.pas

Well, not if the method is private or protected

Yes, and I never stated otherwise - I just pointed out that you can patch virtual methods selectively by replacing them in the VMT. inherited calls would also still call into the old method with that approach. FWIW the approach you wrote for private virtual method works as well for a non virtual method. In fact the technique of hooking methods by placing a jmp has nothing to do with how the methods are being called. Especially for patching known code (i.e. RTL and alike) I rather write byte scanning code for finding the place I want to patch - yes such code has to be changed when you migrate to another version. But with that you can patch any code even if it's hidden deep within the private section of some classes or in the implementation part of a unit.

Either you know it by looking into the assembly for its call or look for the method pointer in the VMT.

{$APPTYPE CONSOLE} uses Windows; type TFoo = class procedure Bar; virtual; end; procedure TFoo.Bar; begin Writeln('broken'); end; procedure FixedBar(Self: TFoo); begin Writeln('fixed'); end; var f: TFoo; p: Pointer; n: UINT_PTR; begin {$POINTERMATH ON} p := @FixedBar; WriteProcessMemory(GetCurrentProcess, @PPointer(TFoo)[0], @p, SizeOf(Pointer), n); // 0 is the virtual index of the method to be replaced f := TFoo.Create; f.Bar; end. The virtual method index can also be found out programmatically.

When you patch a virtual method you don't need to patch it using the technique to place a jmp into the original code you can directly patch the address in the vmt slot. For that you just need to have the index of the virtual method.

If the code you posted is all the class constructor does it's pointless anyway as string variables don't have to be initialized to empty string.

Eh? No, if I in my host application code keep a TRttiContext and keep around some of those TRtti* instances retrieved they will be or contain dangling references. The removal of TRtti* instances of an unloaded module is triggered from TRttiPool.GetPackageList which only triggers if I go through any methods of TRttiPool which is an internal class accessed by TRttiContext. Been there, suffered from that

You only ever have to worry about dropping the TRttiContext when you unload modules such as dll and bpl during your application livetime from whom you needed rtti because then the type information from those modules is not removed and might still hang around possibly causing some issues.