Remy Lebeau

Despite its name, UCS4String is not actually a native string type, like (Ansi|Raw|UTF8|Unicode|Wide)String are. It is just a dynamic 'array of UCS4Char', so a null UCS4Char is added to the end of the array to allow for null-terminated-string semantics, ie you can type-cast a UCS4String to PUCS4Char and iterate the string up to the null terminator, just like any other null-terminated P(Ansi|Wide)Char string. UCS4String was introduced way back in Delphi 6 (when UTF8String was first added as just an alias for AnsiString), so it couldn't be added as a true native string type back then. They never made UCS4String into a native string type, even though the RTL is now flexible enough to support a native string with 4-byte characters. All of the necessary plumbing was added in Delphi 2009 when UnicodeString was first introduced and UTF8String was turned into its own unique string type. UCS4String could easily be made into a native string type now, if they really wanted to. They probably haven't done so yet because UCS4String is very seldomly used by anyone, so they likely didn't want to waste development resources on it. Yes, because Length() is simply returning the full array length, which includes the null UCS4Char at the end.

It was introduced in Delphi 2007 for .NET, so it might not have been available on the Win32 side yet.

The TDictionary in question is the FFormRegistry member of the FMX.Forms.TApplication class. It is used internally by TApplication in its CreateForm(), CreateMainForm(), RegisterFormFamily(), and GetDeviceForm() methods. For what reason, I have no idea.

Yup, I've been in the exact same boat. That's why my big monolithic (C++Builder written) app still works fine for over 2 decades, and our .NET ported web-based app doesn't 🙂

That implies that a non-nil TObject is being released by ARC, and the TObject itself is likely invalid. That call stack shows the global TApplication object being destroyed, which in turn is destroying an internal TDictionary<String, TList<TFormRegistryItem>> object. Looks like perhaps the destruction of one of the stored TFormRegistryItem objects is what is crashing.

Because the error is happening inside the debugger itself, which is obviously written in C++. Maybe this will help you: 64-bit Debugger Assertion Failure lastErr == WSAEINTR Can't run new project in win64 mode, but win32 mode works fine

The List Separator is expected to be 1 character, but is documented to allow up to 3 characters: Doubtful, but the API is probably intended to handle MBCS characters, which I would expect the API to convert into proper UTF-16 characters when queried (and hopefully they fall into the U+0000..U+FFFF range so they fit into a single Char in Delphi 2009+).

On Catalina, you can use PAServerManager instead of PAServer directly, but do note that PAServerManager does have one known issue, at least: RSP-26374: PAServerManager on macOS Catalina don't store its config

Yes, WH_(SYS)MSGFILTER hooks are injected into every process that is being hooked, if hooking other processes than the one that is installing the hook.

Which specific environment variable are you trying to set?

I have seen many people report many problems with the PPL over the years. And for that reason, I REFUSE to ever use the PPL at all. I don't trust it. It hasn't worked right since day 1, and Embarcadero just can't seem to get it right. I prefer to stay in control of my own threads.

That leak report is suggesting that a UnicodeString allocated when the TCanvas.Font property creates its HFONT handle is being leaked. Why, who knows. The only UnicodeString I see allocated in TFont.GetHandle() is from a call to System.UTF8ToString(), and the compiler should be cleaning up that UnicodeString automatically when TFont.GetHandle() exits. That being said, do note that TBitmap and TCanvas ARE NOT THREAD SAFE. One thing I notice in your code is that you are unlocking the TBitmap canvases after drawing, but you said that the TBitmap objects are being "freed later". As soon as you unlock the canvases, the main UI thread is free to swoop in anytime and free the GDI resources behind the TBitmap objects' backs. That very well could cause race conditions that lead to problems. You have to keep the canvases locked for as long as you are using the TBitmap objects in a thread. Otherwise, don't use TBitmap in a thread at all, use straight Win32 API calls instead.

That should be using addFlags() instead of setFlags(). By using setFlags(), you are overwriting your FLAG_ACTIVITY_NEW_TASK flag. You can still use TJnet_Uri.JavaClass.fromFile() in earlier Android versions. You didn't need to change that part of the code to use TJnet_Uri.JavaClass.parse() instead.

Thanks, I'm already aware of that implementation. I had discussions with the author about it, I just haven't had a chance to incorporate it directly into Indy yet: #49 Create an SSL IOHandler for Win32 that uses Microsoft CryptoAPI instead of OpenSSL

Well, how do you expect people to help you when you don't show everything you are doing? How do you know the resources are even being leaked at all? Do you have a leak report from somewhere?

Are you ever Free()'ing the TBitmap that you Create()? The code above does not show that. If you are not, then not only is the TBitmap being leaked, but all of the resources associated with the TBitmap.Canvas (its Brush, Font, and Pen) are leaked as well. And in the code you showed, it is possible that those resources are not being allocated until the call to Canvas.CopyRect(), which is why you would think CopyRect() is the source of the leak.

You are simply not allowed to use `file://` URLs to share files via Intents anymore. Which means your call to Uri := TJnet_Uri.JavaClass.fromFile(AttachmentFile); Will still produce a valid 'file://' URL, you just can't use it in your Intent anymore. You need to add a FileProvider to your Android app and manifest, and then you can use 'content://' URLs serviced by that provider for any files you want to share access to. See Sharing files and Sharing files through Intents: are you ready for Nougat? for more details.

That hasn't been my experience in my 20+ years using (almost exclusively) C++Builder.

Because it still has access to the VMT of its own class type and its ancestors, so will still respect virtual dispatch for that part of the class tree. It just does not have access to the VMT of any derived classes. But, to be honest, in what use-case is it ever useful to call a virtual class method inside of a static class method in practice? The whole point of static is to ignore particular instances, and polymorphism is all about focusing on specific instances.

If you do that, you will need to use the 'delayed' keyword on those function declarations if you want your app to run on pre-W7 systems. Then you can use the functions on W7+ only, and fall back to SetThreadExecutionState() on pre-W7 systems. If you really wanted to be slick, you could then use SetDliFailureHook2() to detect when the Power...() functions are not available at runtime and re-map them to custom functions that allocate a memory object and pass its details to SetThreadExecutionState() as needed. Then your code could call the Power...() functions unconditionally on all Windows versions.

The *correct* way to block the screen saver on XP and later is to use SetThreadExecutionState() with the ES_DISPLAY_REQUIRED flag: PBT_APMQUERYSUSPEND is just a *request for permission* to suspend the system. The system is not actually suspended yet. So you should not be setting your SystemSuspended flag to True in reply to PBT_APMQUERYSUSPEND, only for PBT_APMSUSPEND. And then clearing the Flag in reply to PBT_APMRESUMESUSPEND and PBT_APMRESUMECRITICAL, not just for PBT_APMRESUMEAUTOMATIC. SC_SCREENSAVE and SC_MONITORPOWER are not window messages, they are flags of WM_SYSCOMMAND, so your 1st "If" block will never evaluate as True. Same with the last "If" block here, too. Also, per the WM_SYSCOMMAND documentation:

Note that CodeCentral is going to be shutdown soon, see The future of CodeCentral announcement in the Embarcadero community.

There used to be several in Quality Central, but they were lost during the migration to Quality Portal and the shutdown of Quality Central.

A Handler callback (what TService uses) can receive only the following control codes from the SCM: SERVICE_CONTROL_CONTINUE SERVICE_CONTROL_INTERROGATE SERVICE_CONTROL_NETBINDADD SERVICE_CONTROL_NETBINDDISABLE SERVICE_CONTROL_NETBINDENABLE SERVICE_CONTROL_NETBINDREMOVE SERVICE_CONTROL_PARAMCHANGE SERVICE_CONTROL_PAUSE SERVICE_CONTROL_PRESHUTDOWN SERVICE_CONTROL_SHUTDOWN SERVICE_CONTROL_STOP User-defined codes A HandlerEx callback can receive all of the above controls codes, as well as the following additional control codes: SERVICE_CONTROL_DEVICEEVENT SERVICE_CONTROL_HARDWAREPROFILECHANGE SERVICE_CONTROL_POWEREVENT SERVICE_CONTROL_SESSIONCHANGE SERVICE_CONTROL_TIMECHANGE SERVICE_CONTROL_TRIGGEREVENT SERVICE_CONTROL_USERMODEREBOOT In addition, when a service registers its HandlerEx callback, a user-defined context value can be passed to the HandlerEx whenever it is called by the SCM. That option is not available when registering a Handler callback. Also, there are newer APIs for apps to interact with the SCM, like ChangeServiceConfig2(), ControlServiceEx(), EnumServicesStatusEx(), QueryServiceConfig2(), QueryServiceStatusEx(), etc.

A long time ago, yes (amongst several others). BlueStacks "worked", but it was pretty slow and unstable at the time, though. Maybe that has changed over the years, I don't know.