Lars Fosdal

Looks like you are right, and according to this thread,

TBitmap can be created and manipulated in a thread, but there are caveats. https://www.google.com/search?q=delphi+tbitmap+threadsafe

We create all these in code. No visual components used. We have no sea of DB components floating in designers. It requires a bit more scaffolding code, but it can be generalized and made threadsafe.

The challenge is that to do the drawing, you need a long series of calls to retrieve device info as well as setting up values and UI elements. When accessing the UI in it self is not threadsafe in the underlying OS - it becomes pretty much impossible. Windows UI APIs - not threadsafe Linux Gnome GDK/GTK+ - not threadsafe Android UI toolkit - not threadsafe Apple iOS UIKit - not threadsafe and creating the control structure is such a miniscule task in itself. Of course you can build data structures, models, etc in a thread, but the real work happens towards the UI - which cannot be made treadsafe.

This is why you have a product team. A group of people that knows the problem domain, the IT technology, the operative side, the enduser side. Summary There is no single one true solution Change is inevitable Adapt and overcome

That is more or less the industry standard of how to authenticate.

To decide if a library is relevant, start with identifying your needs. What are the must-haves. Then, make list of options (i.e. different libs, VCL, FMX, TMS, DevExpress, etc) and start ticking boxes. All of these have a massive amount of functionality, so it is impossible to give a blanket recommendation. To give f.x. DevExpress a "must have" status, depends entirely on your needs. In the end, you need to decide if the price is worth it.

Mine takes the SQL table create statement and creates the wrapper class in Delphi, as well as the database stored procs.

On the contrary, more and more of our services are off-prem in-cloud. Yes, there are situations where this is bad - but there are ways to remedy this - f.x. with on-prem caches for production related data. As for loss of connection to internet - with multiple diversely routed ISPs as well as 4G/5G backup - that scenario is not really present for us. As always, there is no one-solution-fits-all, but right now, the pendulum is way over towards cloud hosted web apps.

Personally, I think ChatGPT in it's current form is nearly useless for code generation. The examples it produces are trivial, and in many cases incorrect, incomplete or dangerous. Take the SQL - I've been indoctrinated with the notion that you don't do insert/update/delete statements from applications. You create SQL functions that do that job, and send the parameters. Why? Because you can grant execute rights to the user for these functions, and deny them the option of doing direct insert/update/delete - and hence reduce the risk of SQL injection significantly. The ability of ChatGPT to analyze and describe code is handy, although, I would not consider passing proprietary code to ChatGPT. It does not forget, and you risk that code, model or algorithm will be exposed in somebody elses response. And, although it is alluring, if you use ChatGPT to educate you in code that you have not used before, you have very little insight into the correctness or completeness of the code. I am going to wait a generation or two until the flaws have been addressed, and stick with using the AI to create interesting images. Edit: It struck me - ChatGPT for code is like Autotune for vocalists. It can be used for interesting effects, or making the mediocre presentable.

What lacks in this example is that the bearer token can be a temporary token, and you first have to authenticate to retrieve the bearer token and the renewal token, and use the renewal token periodically to update your tokens.

The enterprise loves this because of zero deployment As long as your desktop/laptop has the appropriate browser, all you need is the URL. No need to install, update, patch, and you can work from anywhere without an high-powered laptop. Rolling out apps to thousands of PCs is a chore - and maybe the user have installed something that interfers with the new version. Rolling out a new web version is simply a tweak of a URL redirect, rolling back - the same. No deployed files that can be copied and reverse engineered or used without credentials. As for the quality of the web apps - that varies a LOT - but the good ones are on par with the desktop editions.

What is it supposed to do? If it is only simple local logging, there are alternatives?

Just keep reporting them, and we'll clean house as soon as possible.

I spotted this. Not sure if relevant? https://stackoverflow.com/questions/45502430/how-to-access-camera-on-a-windows-tablet-with-firemonkey

What about the Windows permissions? https://support.microsoft.com/en-us/topic/87ebc757-1f87-7bbf-84b5-0686afb6ca6b

And there is nothing in the code that eats exceptions instead of exposing them? What about stills? Can you get the example to work?

Ah, in that case - ensure there is no other software that might grab the camera instead of your app?

https://blogs.embarcadero.com/delphi-digital-fan-art-and-ai-art-contest/

You have not identified the type of device, so I assume Android and/or iOS. Has the app requested the right to use the camera? Has approval been given? Ref: https://docwiki.embarcadero.com/RADStudio/Tokyo/en/Uses_Permissions#camera

You still haven't explicitly defined the required precision? Anything timing related on Windows is a gamble err, calculated risk, unless you go to driver-level, and even then it depends on Windows not being starved for resource.

We've not experienced any significant problems with it, but then again, our apps run in a controlled environment.

Did you report the problem on Quality Portal?

Yes. I wrote it, and it has been used in production for nearly a decade.

Windows standard app CharMap is another option.