Lars Fosdal

Discovery = DFS Processing = BFS on Discovery -> Parallel worker threads processing queue? The efficiency depends on a part of Windows file share architecture that I have never dived deeply into. Coming from a single remote computer, will multiple concurrent file accesses be truly parallel, multiplexed or serialized?

It could, if more people actually bothered to. But, yeah... I hear you.

Vote like the feature depends on it!

I've always installed it under Program Files. Mostly because the corporate group policies give me a lot of hassle if I put stuff in "custom" places.

Please report it to EMBT

Yes, providing the LSP log would be very helpful.

Thanks, Leif! Brainfart, I guess. Fixed the broken link in the original post.

Please create a report on qualityportal.

@vhanla - create your report in qualityportal. This not an Idera site, so just writing about it here will not be helpful.

The new Error Insight is GREAT! It works really well! After years of red squigglies for things that are not wrong, it is really nice to only see squigglies when something actually is wrong.

Hopefully, this could be a short thread. This report shows the last thirty days of RAD Studio reported issues. At the time of posting, 31 has been created today. https://quality.embarcadero.com/secure/ConfigureReport.jspa?projectOrFilterId=project-10000&periodName=daily&daysprevious=30&selectedProjectId=10000&reportKey=com.atlassian.jira.plugin.system.reports%3Arecentlycreated-report&Next=Next

Thank you for these awesome tools, Vincent! The combo is used to manage our builds, unit testing and devops style push to test facilities. We are very happy with Continua CI and FinalBuilder and cannot do without them!

Daniele's site seems to be blocked by the Syntax Highlighter from AlexGorbatchev.com being unreachable.

TMemo wraps a native windows control. TVirtualTreeView, all custom. Not sure if you can adujst tab rendering in TVTV, but you can set tab stops in TMemo http://delphitipsandtricks2.blogspot.com/2012/03/set-tab-stops-for-tmemo.html

What about registering the base form? Open form, right click, register

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>.