Rollo62

Thanks, this is what I found too, see my original post. Nevertheless there seems nothing from the official Apple sources or forums.

You could consider a more asynchronous design, for example with TTask, that could avoid the pitfalls of Applicaton.ProcessMessages completely. The use of immutable objects could make your design even more robust. procedure TMyProcess.RunMyProcess; begin TTask.Run( procedure var LImmutableStatus : TImmutableObject; LImmutable : IImmutableObject; begin try LImmutableStatus := TImmutableObject.Create; while ProcessIsRunning do begin Step1; Step2; LImmutable := LImmutableStatus.Clone; TThread.Synchronize(nil, // or better TThread.Queue( if you want to avoid blocking procedure begin { Update User Interface } UpdateUIWhenNeeded( LImmutable ); LImmutable := nil; end ); Step3; end; finally TThread.Queue(nil, UpdateUIWhenNeeded ); LImmutable := nil; LImmutableStatus.Free; end; end ); end; Just as a rough idea, without checking your specific needs.

Have you tries with the SDK/NDK/JDK that are shipped with the Delphi originally? https://delphiworlds.com/2024/04/delphi-12-1-and-codex-2-2-released/ I think this might be critical, because of the deep changes in this Android tools and internals. I would recommend to stay with the original D12.1 setup and files in the first place, if there is no specific need to really upgade the SDK.

Good thing that 👍 But can anyone open the RSS-425 ? The rest is working well.

https://blogs.embarcadero.com/6-books-about-delphi-you-should-read/ https://en.delphipraxis.net/topic/10623-good-delphi-learning-sites-for-new-team-member/?tab=comments#comment-84363

Hi there, I want to share some insights, to change the "Release notes" of an already published version, without uploading a new *.AAB version. From time to time you had just uploaded and publishes a new release, but you find some better or more description under the "Whats new" section of the Play Store. You can change this without uploading a new release, which is not so obvious, because this feature is a little hidden and it took some time to reveal its secrets. Here is the current workflow step-by-step: Enter App page in the PlayStore Enter Production tab on the left navigation bar Select Releases tab Click Manage Release on the right-hand side Scroll down to botton "Release Notes" Click "Edit release details" on the right-hand side Edit and Save Thats all, the changes will appear immediately in the PlayStore, without another review. Nice.

Yes, underlying hardware issues which could causes by various reasons, from permissions to misbehaving sensors and many more. Since then, I enclose all these features inside a double-protection, to be hoepfully able to catch more of such execeptions.

I'm not too deep in these topics, but as far as I know, the runFullTrust capability seems to be required: https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations#restricted-capabilities, at least for certain permissions or operations:

Perhaps this did the trick: https://en.delphipraxis.net/topic/11151-delphi-and-use-only-memory-safe-languages/?page=5&tab=comments#comment-90366

Hi there, as you have might have noticed, the ChatGPT PluginStore is already removed and will be completely shut off soon. Winding down the Plugins-Beta Nevertheless, there is still an option to run ChatGPT with Plugins up to now: https://chat.openai.com/?model=gpt-4-plugins Hope that helps anyone.

Yes, they already removed the plugins from the Pro plan. With the tip above you could at least still reach them ( not sure for how long). If you look for prompt design tipps, I haven't looked recently. I think its always good to check current state, since this might change daily. A good start would be at OpenAI's instruction perhaps: https://platform.openai.com/docs/guides/prompt-engineering Here is some interesting training site, how to improve your prompt skills learning by doing, but I doubt this is nothing more than a nice toy for fun: https://experiments.withgoogle.com/say-what-you-see

My recommendation would be, to avoid 3rd Libraries as much as possible. Since FMX on Mobile is very volatile and Android/iOS change significantly every 6 months, it is very important not to rely on additional, possibly unstable, external components. My recommendation would be, to make as much as possible on your own. I can recommend DelphiWorlds-Kastri as a common life-saver, TMS FNC and other TMS components - since they are quite active, but I would still reduce any external reference as much as possible. Moreover, I would not directly try to port a desktop app to mobile. Better to start clean with a mobile-first app and then put your "desktop" functionality back step-by-step.

Do I get this right, no browsing function yet ? Or will this be activated later? So far, this morning, I could find nothing.

Yes, you can safely ignore them ( until Google decides to enforce this probably in the future ). I considered that too, but I'm afraid these warning will be hard to remove, because they require certain Android tools, like ProGuard. Not sure if this will be ever included in the Delphi process. One idea, at least for the first warning, was to add a neutral or empty "manifest.txt" file. This might work technically, but on the other hand, the Google Review might see this as an attempt to circumvent or infringe their PlayStore policies, which might put you in bigger troubles. My hope is, that Embarcadero put this onto their roadmap.

Nice list, thanks 👍 You missed these few, probably: https://rosettacode.org/wiki/Parse_command-line_arguments#Delphi https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.SysUtils.FindCmdLineSwitch https://github.com/exilon/QuickLib/blob/d085aa28e5fd65bae766446f5355ec4dc80fae9e/Quick.Commons.pas#L1292 https://wiert.me/2015/05/13/on-the-delphi-tcommandparser-class-for-parsing-command-lines-and-arguments-via-suggestions-for-how-to-define-command-line-parameters-stack-overflow/ https://github.com/jackdp/JPLib/blob/master/Base/JPL.CmdLineParser.pas https://github.com/tokibito/delphi-argparse

I did, but I would wish a little more screenshots, to understands what is this all about.

Could this have something to do with it? https://blog.marcocantu.com/blog/2023-october-nativeint-weak-alias.html Like Uwe said, a little more code would be nice.

More on memory safety, from Marco Cantu. Regarding marketing, what comes into my mind is: Can the memory safety of RadStudio C++ safely assumed to be more improved than standard C++, because it's close relation to its sibling Delphi within the same package? My marketing mind screams: Of course RadStudio C++ is advanced, because the memory safety of RadStudio Delphi rubs off on RadSudio C++. P.S.: "rub-off" is a professional software developer term, that decision-makers in government and elsewhere can easily adapt and understand.

Well, you are so far behind, that you are already far far ahead .... in our cyclic universe

The ExoPlayer in its old form is deprecated, does this Alcinoe library also works in the new Media3-Version?

The exception mask is touched by a few internet or browser related units: I'm not too deep in the exploration of the ExceptionMask-business, but probably it would make sense, to separate those concerns, by units with specific defines in a conditional compilational way. That way, standard-apps ( without internet / browser ) will be able to have all equal settings over all platforms, right? Only when using a browser, then this would need to be considered as a separate case. I'm not sure what the pro's and con's would be. To be honest, the internet is everywhere nowadays, an assumption that the browser is available by default, is a fair choice too.

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.