Lars Fosdal

You also have WM_WTSSESSION_CHANGE that give some messages that allows you to take precautionary actions. https://docs.microsoft.com/en-us/windows/win32/api/wtsapi32/nf-wtsapi32-wtsregistersessionnotification https://docs.microsoft.com/en-gb/windows/desktop/TermServ/wm-wtssession-change procedure ON_WM_WTSSESSION_CHANGE(var Message: TMessage); message WM_WTSSESSION_CHANGE; Note that WTS_SESSION_TERMINATE does not actually work, though.

My employer gets the bills, we developers get the invites - but it wasn't always like this. We pestered our local sales rep to fix it.

At the time, my son was using a Pocophone F1 also running Android 9, and his phone did not kill the app. My 7 Plus also was on Android 9, while the 3a XL is on 10. It could be OS specific energy saving settings that govern how quick it is to kill apps. Otherwise, I totally agree on sensible state saving and restoring on reactivation. Are there other stay-alive options than navigation, without running as a service?

This is something that has puzzled me with Android apps. Background: In Norway, we have a walkabout game app ("Stolpejakten" which translate to "The Pole Hunt" ) which has you locating real world markers via a map, and when you arrive at the location, there is a QR code on a wooden pole that you scan to register at the location. It is a nice motivator for extending your walks for "just one more marker". The app uses the GPS to indicate your location in relation to the marker, the app has a somewhat lengthy startup, apparently logging onto a central server, loading the maps and pole locations, and marking your latest marker visits, and restarting at the "home" screen, and not where you last left off. Hence there is a very visible difference between waking up a sleeping instance, vs a dead instance. On my Nokia 7 Plus, this app would go dead in a few minutes behind the lock screen, but on my Pixel 3a XL, it will stay alive for a fairly lengthy period, although sometimes it can die rather quickly. Question: What can prevent or at least reduce the chance of the app being killed? What governs the "survivability" of your app?

That depends. I don't know if the LastError thread var is cleared on a new thread, or if you must do it yourself. SetLastError at thread start will at least ensure it is cleared, but without knowing the code being run, it is impossible to assess if there is any point in doing a "blind" GetLastError. If there are multiple calls to Windows functions in that code, what value is there in only showing the last one? Was the error situation handled without LastError being cleared? Is it then really an error anymore?

This is why Anders' advice is good advice: https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setlasterror

VS is 32-bit. I bet MS would like for it to be 64-bit as well. We'll get there, eventually. VS Code is 64-bit, but that's just an editor and it is Electron-based.

Your problem is with LiveBindings. http://docwiki.embarcadero.com/Libraries/Rio/en/System.Bindings.EvalProtocol.EEvaluatorError I don't use LiveBindings, so I don't know how to solve your problem.

Are you using Format? You should be using FormatDateTime. FormatDateTime('dd.mm.yyyy', Now); should yield '11.05.2020'

I've also seen compile time issues where you must specify the type T of the iterator for a TArray<T>.

Can you use ligatures as operators in the actual code?

I press Ctrl-S waaay to often, even with the autorecover enabled. The habit is caused by working in an IDE that has a bad tendency of locking up or suddenly go dying.

Losing 40 minutes of work should be impossible in Rio.

Why do you need that in a code editor?

We make extensive use of frames in VCL. For FMX, it is not quite as clear cut...

Is it relevant? OP referred to the clone as well.

https://github.com/sglienke/Rapid.Generics does state "Rapid generics/defaults equivalent classes for Delphi (2010+)" But yeah... there have been a lot of changes to Generics code generation since XE.

I see the change went through. All you need now is a friendly avatar 😉

That sums it up. Use the xml doc feature for methods and properties, and do it straight away. If it is postponed, it never happens. A colleague asked me on how to use a specific feature yesterday... So... I opened a couple of related units I wrote some time ago, and they had NO xml doc, so yeah, that never happened. The interface sections alone are 1070 and 350 lines, so... I guess I really should work more on my own documentation rather than offer advice To my defense, they are widely used in our projects, so there are plenty of usage examples

To make it simpler for your user to make the change, If you open "ms-settings:taskbar" in an explorer, you go directly to taskbar settings. Not sure if there is an URI that goes directly to the icon in tray sub page. https://www.askvg.com/list-of-commands-to-launch-specific-settings-page-directly-in-windows-10/ This seems to bring out the old school tray icon settings, but I would assume that the days are numbered for that page. "explorer shell:::{05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}"

It can be found under https://en.delphipraxis.net/settings/ If there is no change link, send a PM to me or @Daniel

When using something new or something you use rarely, writing comments in the code can be helpful. For each unit, mention the related units, how the types relate, how to "set things up" with regards to how to "link" related types. It might feel like waste time since the source is there, but yeah, memory doesn't really improve with age. Also - the idea you had when you broke it into six units, may eventually lead to the removal of units, so taking a note of why the design is as it is, is helpful. I usually know how my libs mature by the amount of code I can delete or simplify. When things gel properly, the solutions often can turn out simpler than the original idea. And then there is the eternal question: Are you solving a problem, or are you writing a framework? My favorite pitfall that I keep falling into.

We do use worker threads that live across TCP/HTTP "sessions". Since the data are so dynamic and variable, it is next to impossible to go fully static on allocations.

Proper load tests are challenging since it they require data that make sense on many levels. I probably would have to try it in a live situation.

So, our multithreaded TCP/HTTP event driven services do a lot of string manipulation, copying to/from buffers, converting objects to/from json / xml, etc. Can I expect FastMM5 to increase the throughput?