Remy Lebeau

When I first started using this site on mobile, it took me a LONG time to find the option there. Definitely not the most intuitive place for it. I would have expected it to be under "Activity" along side the "Unread Content" option.

I don't understand what is confusing about it. Actions have several properties and events that apply to Forms just as they do to any other UI control.

The same could be asked for any UI control that has a published Action property and a published OnClick (or other actionable) event. One reason is code reuse, the same Action object can be assigned to multiple controls, even the Form itself. For instance, Actions are commonly shared with menu items and other UI controls that invoke the same actions. Another use would be sharing common properties with multiple controls (Enabled, Visible, etc) so you can update 1 property and have it propagate to multiple controls automatically.

Sadly, you won't be able to do that with FMX's TWebBrowser. It simply doesn't have the necessary functionality for that (only VCL's TWebBrowser does). If you really want to use FMX's TWebBrowser, then I suggest using TIdHTTP or other HTTP client for the actual HTTP communications, that way you can automate it however you want, and just use TWebBrowser to display the HTML (or whatever) you retrieve, such as via its LoadFromStrings() method. And then use TWebBrowser events to block the browser from making HTTP requests, redirecting them to your HTTP client of choice. The experience won't be as seemless as a standard browser, but it will give you more control.

A better solution would be to forgo the TWebBrowser frontend altogether and redesign your web app to accept REST requests on the backend server to do the work you need. Then use a standard UI on the client side to display the results as needed. You would have to check if the underlying platform browsers provide any APIs to automate them in code. VCL's TWebBrowser is a wrapper for Internet Explorer and exposes access to its DOM API. FMX's TWebBrowser does not expose similar functionality.

Correct. There is not, because you cannot combine 32-bit and 64-bit code into a single executable, so you will need separate 32-bit/64-bit DLLs, and thus will need separate 32-bit/64-bit processes to install their hooks into target 32-bit/64-bit processes.

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.