Leaderboard

No official fix as yet, however I have come up with the following workaround - Note: this has had no testing beyond a blank app: 1. Copy FMX.Platform.iOS from source\fmx into your project folder. 2. In the TApplicationDelegate.applicationDidFinishLaunchingWithOptions method towards the end, make the following change (i.e. add the one line of code indicated😞 // Creating window WindowManager := PlatformCocoaTouch.WindowManager; WindowManager.Window := TFMXWindow.Create(MainScreen.bounds); WindowManager.RootViewController := TFMXViewController.Create; // *** iOS17 SDK crash issue - Add the following line: *** WindowManager.RootViewController.Super.init; WindowManager.NativeWindow.makeKeyAndVisible; Note also that this measure is needed only if you are building against the iOS 17 SDK - it is not required when building against earlier SDKs.

Now there is the rub! A 64Bit IDE will be experimental at best. Quite the contrary to a stable IDE. Just consider the introduction of DelphiLSP. Now that Baby started birthing more than three years ago, and it is still not "robust". I'd prefer them to fix the 32Bit IDE to reach a robust stage over them pulling resources to that new construction site.

The address space of a 32-bit application is 4GB. Some of that is reserved by Windows. By default 2GB but for Large Address Aware applications (such as the Delphi IDE) it's 1 GB. These values can be customized globally. Your hardware configuration (motherboard, etc..) can have an effect on the reserved size, btw. https://learn.microsoft.com/en-us/windows/win32/memory/virtual-address-space If you are running out of memory at 2.5GB then the IDE is trying to make an allocation of 0.5 GB or more. This seems unlikely so there could be something else going on. You might wait to check the size of "hardware reserved memory" on your system. 100 forms open at the same time is hardly a typical use case. Why would you ever want that? FWIW, I just tried opening all the over 600 forms, frames and datamodules of a project with around 3 million lines of code. It uses DevExpress ribbon, docking, skins, grids, and controls, FireDAC, etc. That consumed 3.4 GB but happily compiled and linked. It's a 64-bit project. I'm not saying that your problem isn't real but I don't think this problem is common enough that it alone justifies migrating the IDE to 64-bit. And I certainly don't think your rhetoric will help your case.

Look-up base64 conversion in the help, then break the lines to 64 long and add the --- header and footer you see in a PEM certificate file. Angus

I which type of variable to you get that data?

Ok thank you for your hard work with that.

I've tested this fix on a more complex app too and it also stops the crashing issue on iOS 17, so thank you as always Dave!

Hi... Why? This is not in accordance with the official style guide. https://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi’s_Object_Pascal_Style_Guide I know that you can create your own styles. But do you think about those who get your source code and can hardly read it?

I always liked the concept of splines a lot, and here is now the reason why https://www.youtube.com/watch?v=jvPPXbo87ds This beautifully unveils all hidden secrets about it ( Ok, not all, hopefully more to come ).

Love the engagement here from the poster