Dalija Prasnikar

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.

They fiddled around with theming support in 10.3.3 and there were some changes... apparently not all were for the better. Right now, theming is my number one suspect when IDE is misbehaving... and (unfortunately) usually I am right about that

@Phil J. If I may ask, what are your computer specs? CPU, screen resolution, graphics card? I would like to file issue in Quality Portal so adding those specifications might help in pinpointing and fixing the problem for the future. I don't think it can be completely fixed because using styled custom painting on top of Windows controls can never be as fast as plain Windows painting, but speed improvements might be possible.

Delphi Rio introduced new IDE styling (themes) that are not exactly super performant. If you have older computer, you might have some issues. I don't think you should have as much problem as you describe, but anything is possible. You can try disabling new IDE theming and use default Windows theme. You can find how to do that at https://dalijap.blogspot.com/2019/05/disable-delphi-rio-ide-theme.html I have to mention that using Windows theme is no longer officially supported and you can run into some issues because of that. I have been using Rio with default Windows theme since it was released and I didn't have any major issues (ones I did have - crashes in GetIt package manager and Find in files) have been resolved in the meantime.

I never realized Web installer also does that. I use migration tool, and I always uninstall first manually.