Leaderboard

Selective Debugging allows to select the debug DCUs on a per unit basis. This doesn't affect the content of the call stack. Honestly, I doubt that removing this information from the call stack is of any benefit at all. In fact it would camouflage the actual program flow rendering the call stack next to useless.

Easily resolved by removing F-Secure. As with so many anti virus products the cure is so much worse than the disease.

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.

I don't ever use the OnExecute handler, but I generally use the OnUpdate handler to update controls that does not support actions themselves. I guess one could also use it to control TForm.Enabled but I've never had a need for that. The forms OnUpdate handler is also convenient when modernizing applications that were written without TActionList. These tend to have a single method that contains all the UI update logic. I move this logic into the OnUpdate handler, review and remove all the calls to the old update method and then start migrating the logic to individual actions. I mostly end up with some logic that can't be handled by actions and so it stays on the forms OnUpdate handler.

Jack of all trades, master of none - seems to be my modus operandi, which is more or less the same as sucking equally at everything 😉

TestInsight does no magic in terms of "running tests" - it simply does the same as Run/Run without debugging. The client code then communicates via tcp/ip to the IDE to ask which tests are checked when you only want to run a limited selection and reports the results. However in the few times that I had to run tests on mobile myself the experience is not as smooth as with windows, linux or osx that all support some UI less application that simply starts, runs tests and closes. So I usually had some minimal FMX UI that showed the tests and had a run button or something.

You mean "doing something with computers" is useful? If you really wanted to learn something useful, you should have learned gardening, masonry or carpentry. 😉

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