Rollo62

Thanks for pointing to this nice page, which shows the overview of old and new behaviour nicely. http://docwiki.embarcadero.com/RADStudio/Athens/en/Floating_Point_Operation_Exception_Masks I've tried to summarize that and make the relevant differences even more visible in this overview:

Thanks for the links, but what made you think C++ fails to be the best language. Only because you can do nearly everything you like, even things you shouldn't ? I always state that you should better use only 80 % of such language possibilities and stay away from the latest cool hype stuff. At least I would say that C++ is mature and rock-solid in any way. To get back to try-except: The last time I learned about Pascal-vulnerabilities, it shook me and I understood many of the sporadic issues I saw in mobile development. Thanks to Dalija's blog posts. Not to be able to rely on exception catching the way I expect is breaking the foundations of my small, parallel world Unfortunately, I would not say that Delphi is superior to C++ in any way.

It worked for me too, but placing a SubForm on a main form turns out to assign (copy) all components parents from the SubForm to the main form. I use carrier components (TLayout, TPanel, ...) here too, so to be able to assign a SubForm-Carrier parent to a carrier component in the MainForm. Perhaps there are different methods to achive that too, but I found this was the only reliable solution at that time.

I would disagree, at least from my point of view. I used try-catch in C++ on a regular base, even years ago, and find them even more flexible and more clear to use than try-finally-except.

I get your point, but it's maybe an issue of wrong usage of terms here. When talking about memory-safety: Delphi is NOT When talking about: system-vulnerability-safety (or the like): You could probably argue that it's better than C++, closer to behaviour as JS, but I doubt that too.

Like said, this is probably working also without splashscreen. Have a try.

I use frames as complex, visual UI much like a component without creating a real IDE custom component. While it still has the advantage of visual design. I use mainly FMX, but that should work same under VCL too, by using an interposer class of TFrame, for easy management. At runtime I add them to a special "carrier" in the parent form or frame, which can be TRectangle, TLayout or other. So this is not a drag-and-drop approach, but the runtime approach works very well and gives a lot of flexibility and stability.

Are you aware of the splash-screen page, with background color options? https://docwiki.embarcadero.com/RADStudio/Athens/en/Application_Icon#Android I still use the old style of background color, which was changed in D12, but it should still work. Additionally, you could check the ViniciusFfb repository here, which shows other options too.

Exactly, that's why I laughed about that whole discussion, because the core question is pretty clear. Maybe I should add an <irony> tag, to make that more clear to everybody. The core question: Delphi is NOT memory-safe ... period. If some institutions think otherwise, and Embarcadero likes to use that statement for marketing purposes, ... so what?! Do you expect Embarcadero shall deny and contradict such an official statement from the government? Probably not, I wouldn't do either. Let's embrace these statements and use them as marketing for Delphi too. Every help from inside and outside is welcome, IMHO.

Who cares, it sounds good anyway.

This has bubbled up to an official statement now, I like these fast reactions 👍 https://blogs.embarcadero.com/is-delphi-a-memory-safe-language/?utm_source=Eloqua&utm_medium=email&utm_content=Article-240311-Multicontent

Ok, psssst, please don't complain so much

Why why why is installation and using SSL and TLS still such a big mess in D12? I have never understood why this important field of development looks so deserted, with only a view of a wide-open junkyard of the many newly invented wheels. I thought Embarcadero was working on a better integration of OpenSSL/TLS in D12?

Perhaps because of the myth and the old tale from days long gone about the high type safety level of Delphi and the banishment of pointers in that language.

However, I now see things completely differently. I have to deal with EU compliance rules for various products and see new rules and regulations being pushed through almost daily, regardless of the consequences. This is not about lobbying, but entire industries are being dismantled for an ideological agenda. This whole agenda is being driven by the USA as a pioneer and when someone there coughs up a new regulation, I already take the whole thing very seriously and prepare myself for the worst.

Regarding the search for arguments: I would not rely on language alone, but I always consider the libraries and frameworks built on this language too. Maybe it is a vague argument, that the language + libraries = can be ( more or less ) memory safe? What I mean by this, is to embrace the use of smart-pointers and forbid to use POC, by help of all possible external tools, strict guides and library tricks. Yes, the underlying language alone is not memory safe and can be forced to fail, but the whole ecosystem could have a degree's higher memory safety index, IMHO, if the libraries are structured well. I did something like this centuries ago, as a kind of simple script language for machine control, which was based on C++ and its wonderful pre-processor. The language could be abused, but the functionality offered by the core library would enforce a higher level of safety than plain C++ alone. Would that be something workable for Delphi too, at least to get it half-way memory safe?

There is another timer implementation within Kastri https://github.com/DelphiWorlds/Kastri/blob/a1ae5aec3146e4c4c61999e2ce8adcb281474a64/Core/DW.OSTimer.pas#L4

Maybe that helps for your considerations? https://github.com/grijjy/DelphiPlatformTimerQueue https://blog.marcocantu.com/blog/2014_may_background_delphi_android_threads.html

Hi there, it seems that Apple moves more and more from Objective-C to Swift, especially for the new APIs, like RealityKit 2 https://developer.apple.com/documentation/realitykit. That would mean Delphi / Firemonkey needs a way to bind with Swift, if no Objective-C might be available. Has someone maybe checked about such Swift binding, and what pitfalls may be there ? I would expect that Swift can handle more features, that cannot really converted to Delphi, but thats just my assumption. Who could give more light to this ? Edit: I had an older post in the german DP, see here, as a kind of cross-post to this topic.

Whishlist: At the moment and in the future, I would like nothing more than for the IDE to always run with all its functions, demos, features as agreed, on all platforms. So that all breaking changes can be communicated and fixed in good time before important AppStore deadlines come into force and that the existing apps can be permanently well maintained. I avoid touching new functions for quite a while now, to limit the pain caused by adding new, half-supported features.

Hi there, I'm currently considering how far I should update my tools and devices, to find random errors. The upgrade process from D11.3 to D12 stuck a bit, and I'm now in between D11.3 and D12 somehow. Since the latest D12.0 supports iOS17.x, but unfortunately doesn't seem to support Device debugging any longer. http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#cite_ref-iOS17_3-0 http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page#cite_note-iOS17-3 https://developer.apple.com/documentation/xcode-release-notes/xcode-15_3-release-notes The question is, how far I should update my devices and tools, what is the best strategy to survive that breaking change. I highly rely on iOS debugging under D11.3, as the last resort to make reasonable tests ( since Android debugging didn't work for a while either ). Without that, the development will be even more hard than it is today. Currently, I want to investigate crashing on an iOS 17.3.1 device, which my latest iOS 16.7.5 device doesn't show. I'm afraid, this will be only possible by upgrading to XCode 15.2 then, as XCode 14.3.1 doesn't support iOS 17 at all. This will kill my ability to debug on real hardware, since I only have x86 Intel Mac available and I'm also out of the ability to use a simulator ( which I really don't want either ). So my hope it, that using XCode 14.3.1, with running and debugging on an iOS 17 device somehow, will be possible, to find issues. Does the latest Patch 1 changes anything on the debugging situation? My question is, to which XCode, IOS versions I shall safely update, when I still need to debug devices? Are there any tricks or workarounds available? The worst case will be to end up with mobile development, where neither iOS nor Android debugging works reliable.

That would be great, but I do see certain different behaviors when I run the iOS 16 App release via TestFlight on an iOS 17 device. Those issues will be hard to find without proper debugging. I think so too, any ideas when a fix will be available? The deadline is around April, I assume from then XCode 15 is hardly required, or allows Apple a grace time until our IDEs will be fixed? Would be great if there would be any official statement about this issue and the status of fixing it. I have iOS 16 and iOS 17 device available, but only a MacBook (Intel), so I cannot use the simulator ( which I also would not put in the ring, if not really needed ). Regarding the XCode internal changes, I'm not clear about how deep they were, but I expect the worst from what I have read so far. If you have more insights about the relevance of the changes, it would be great to get more info. I would assume that linker, debugger, PAServer and a lot more functions were affected.

Yes, but if you touch the Location already in FormCreate, then the permission request comes later, and this will be problematic. That was my point.

Yes, I need debugging on devices, because I need to debug external devices too. Without debugging, this turns out to be a real pain, although I have implemented massive logging meanwhile. In the past debugging worked reliable sometimes on Android, sometimes on iOS / Macos, but always some way to go. In D12 and XCode 15 it seems not to work any longer, no matter what. Another way out would be to imp,ement the according Win32 functions, to at least debug there, but also this is not running out-of-the-box. Before I put too much energy into XCode 15, I better try with the last version, ... time is NOT on my side

It seems that unfortunately nobody else has some more insights regarding Sonoma and XCode 14.3.1 vs. XCode 15.2, so I want at least post my current results here. With the method described, see above, it seems that I could successfully (trick)-install XCode 14.3.1 under Sonoma (Intel), including normal debugging function under iOS and Macos. At least this works for iOS 16.4 devices so far, which is the latest SDK offered, although the iPhone has installed iOS 16.75. I have not yet made experiments with iOS 17, but I will try soon and see how this might behave. At the moment I tested only the Rx12.0 version, without the latest IDE patch, so my next move will be to check the behavior of the Patch 1.