Dalija Prasnikar

While anything is possible, I don't think there is too much ARC only code around. For anything TComponent based ARC was never working in the first place (you had to use DisposeOf) so most of UI code should work as-is. Since manual memory management is what people are used to, migration path should be relatively easy, although it may be harder to find exact places where object needs releasing. I would follow constructors .Create - usually destruction is somewhere nearby - either in Destroy, or in the same method. Also, on mobile small leaks are not that critical, usually applications are killed anyway before such leaks cause substantial problems, and larger leaks are easily found just by looking at code. With Instruments and Android Studio you can easily spot problematic parts of application with large leaks. Not ideal situation... but what is done is done.

https://www.embarcadero.com/products/rad-studio/whats-new-in-10-3-rio https://dalijap.blogspot.com/2019/11/rio-1033-update.html

Have you reported the issue to Quality Portal? https://quality.embarcadero.com/ I am not sure if community edition is eligible for free installation support https://www.embarcadero.com/support If IDE plugins are problematic, maybe it would be best that you avoid installing non essential plugins.

var Strings: TStringList; begin Strings := TStringList.Create; try Strings.LoadFromFile('C:\SomehugeFile.txt'); finally Strings.Free; end; end; Above is trivial example that can easily cause OOM error and it is also simple to handle and fully recoverable. You can easily wrap the whole thing with try...except block, show message to the user and application can merrily go on like nothing happened. We disagree then. Maybe my imagination is at fault, but I have really hard time imagining how would solution with non-throwing constructors be simpler to handle and make code less complex and convoluted.

Every instance construction can fail because of out of memory error. But there is nothing special in surviving such exception. It only depends what you are doing at that time. Whether it will be recoverable error or not depends on the developer. Also throwing exceptions during construction is not a trap... Delphi has mechanisms in place that allow full cleanup and recovery. That is all that matters. If we didn't have exception throwing construction, we would still have to deal with all kind of "exceptional" situations where you would have to be prepared for handling them. And it would not be any simpler than what we have now. Basic problem in this particular case is non trivial ownership transfer, not the exception throwing constructors per-se. Solving ownership transfer solves the problem. Moving construction of dependent class to within owning class eliminates ownership transfer and solves core issue. (Another approach would be using reference counted classes and automatic memory management)

Construction the instance in outer scope is indeed the problem here, but your code still constructs the instance in outer scope. In order to prevent all leaks, instance must be constructed from within the constructor because exception could be raised before constructor chain is called. In such case you still leak TSomeOtherClass instance.

Same way like other approaches (besides interface) by moving construction of TSomeOtherClass instance to TMyClass constructor. Example would depend on DI framework used... I would look at Spring4D... If code is used in places where out of memory is not recoverable error, then ignoring this potential leak is also viable approach in combination with assigning instance at beginning of constructor like @Uwe Raabe suggested

If allocating memory for the object instance fails then destructor is not called. I would probably use try..except block for releasing the object in case of out of memory error. Of course, that works only if constructing TMyClass instance itself is the only thing that can cause out of memory in that process. But I don't really like that whole try...finally block with nil assignment. Cleaner approaches would include DI, interfaces, passing meta class to TMyClass constructor and constructing TSomeOtherClass instance within the constructor, if the construction is too complex then I would use anonymous method instead and use it as factory.

Code is never perfect. You just revisit code months later and some things will inevitably draw attention. Sometimes, improvements are just minor tweaks, sometimes you are like "what was I thinking, this whole thing has to go". Sometimes, you just leave all the horror untouched because you don't have time. It is a never ending story.

If by any chance Dark Mode support does not work properly, you can customize plist and add key to force application into using light mode. See http://docwiki.embarcadero.com/RADStudio/Rio/en/Customizing_Your_info.plist_File and https://stackoverflow.com/questions/56537855/is-it-possible-to-opt-out-of-dark-mode-on-ios-13

This certainly seems like device with dark mode turned on, since TEdit uses native device rendering. There was announcement for 10.3.3 that said plan was to support iOS 13 dark mode https://community.idera.com/developer-tools/b/blog/posts/addressing-ios-13-and-android-64-bit-with-rad-studio and the release notes http://docwiki.embarcadero.com/RADStudio/Rio/en/10.3_Rio_-_Release_3 also mentions dark mode support. But, I cannot find those settings (under Project Options - Version) available in IDE. Maybe it is a bug or it is just too late here...

If you can switch to 64bit, this is the fastest way to solve intermediate memory issues that are not caused by memory leaks. However, additional information about what exactly you are doing would be helpful. Memory issues can have number of causes and solutions depend on root cause. For instance, what kind of file(s) you are importing? How are you processing them? Importing 300 MB XML can easily kill 32-bit application. Even smaller than that can be problematic depending on particular code. Also, if you are parsing textual data, using UTF8String for processing generally reduces memory consumption by half (for Western character sets). Creating DOM is also wasteful, using SAX parsers for XML is faster and consumes less memory.... base64 encoding, decoding can also be a memory killer if you are doing it in memory, with strings... Like, I said... more information is needed for better diagnostic...

https://dalijap.blogspot.com/2017/12/is-it-thread-safe-assume-not.html

This is design error in built in Delphi JSON library. Instead of working with properties it works with fields. https://quality.embarcadero.com/browse/RSP-26262 AFAIK there are some options to add custom converters , but I never used it... take a look at REST.JsonReflect and Data.DBXJSONReflect

Yes, there is. Result :=Default(T);

I have just realized that your path is probably wrong I have it in "C:\Users\Public\Documents\Embarcadero\Studio\20.0\Styles"

VCLStyle entry in registry is not the name of the file, but name of the style in Editor - without .vsf.

For extracting resources Google for PE resource editor. You don't have to rebuild bpl again, just put your VCL Style in common path where IDE can find it (where other VCL Styles are located) and then change following keys in registry: Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\Theme Key: Theme Value: Custom Key: VCLStyle Value: YourStyleName (That would be the name you give in VCL Style Editor under Name Unfortunately, VCL Styles are bitmap based and you cannot just change few RGB color values, you have to edit bitmaps. You can export complete style as one PNG and then you can edit colors in some image editing tool. After you are done, import new image back in. You will also need to go to Style -> Assign Colors to apply colors from bitmap back to Colors and SysColors. After that check if all those colors are correct (I think few were not assigned correctly) Depending on how much customizing you need and want, it can be a lot of work. I modified Light theme to grayscale, but that was rather easy as I just converted whole png to grayscale (except for the close button)

There are few problems here. First, IDE themes are slightly different from general VCL Styles so you cannot use them because some parts of IDE will not be painted properly. Next VCL Style editor is rather hard to use for creating any theme from scratch. Your best option would be to extract theme resource from darktheme260.bpl (haven't checked if this is the right bpl, as I have customized light theme), and then use that resource as starting point for your customization. IDE themes are copyrighted, so you should not distribute such hacked theme.

Also there are some bugs with that circles... Stepping through debugger activates file modified icon https://quality.embarcadero.com/browse/RSP-26776

I didn't either... I was told about that in one of those closed bug reports I made about LF issues.

Tools -> Options -> User Interface -> Editor -> uncheck Preserve line ends

Don't remember exactly... but something along the lines implementing support for <LF> would be too much work, so make sure you have correct line endings in your code. There is also option to autocorrect while saving so that helps with pasting code... where it does not help is if your VCS messes your endings.

All bug reports about this issue were closed as Won't fix.

It is fixed.