Rollo62

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.

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?