Leaderboard

You know that annoying person constantly interrupting and asking you the status of some very busy task you are performing? That person is called Application.ProcessMessages

When I said put your code in background thread, I didn't mean literally like run exactly the same code in background thread. But for any code that runs long, Application.ProcessMessages is always the wrong solution. It may be quick fix at some point, but it is still a wrong solution. First step in writing better code is acknowledging that Application.ProcessMessages is wrong solution. Then and only then one can start going in different direction and start learning and applying better solutions. It can be long process, depending on the existing code you (I don't literally mean you) already have. But the sooner you start, the less work you will have in the future when you start removing Application.ProcessMessages. If you never start doing that, sooner or later you will encounter code where Application.ProcessMessages will not work as intended and you will not be able to make UI fully responsive when using it. Learning how to use background threads at that point - when you cannot properly take time to experiment and learn will only make it harder. It depends, but certainly more often than with Application.ProcessMessages approach.

The code where you call Application.ProcessMessages procedure TMainForm.BtnClick1(Sender: TObject); begin DoFoo; DoBar; DoFork; end; procedure TMainForm.BtnClick2(Sender: TObject); begin DoFoo; Application.ProcessMessages; DoBar; Application.ProcessMessages; DoFork; end; procedure TMainForm.BtnClick3(Sender: TObject); begin TThread.CreateAnonymousThread( procedure begin DoFoo; DoBar; DoFork; end).Start; end; Problem with Application.ProcessMessages is that code that would execute in one block without interruptions, like in first example, can now be interrupted and some other code can start running in the middle of it. For instance you can click same button twice. Or you can close form and destroy it while other code is still running and using it. Now moving in background thread does not solve those issues, because you can still click the button twice and you can close the form while you running something in the background. But, there are few things to consider here. First, while code with ApplicationProcessMessages can be interrupted at any point, code in background thread will run serially, one line after the other, just like the code that does not call Application.ProcessMessages. It is far easier to follow the logic (and debug) such code. One of the arguments for Application.ProcessMessages was that it is easy to use, comparing to multithreading. That is true only on the surface, it seems easy and that is why we were all using it. So you have beginner developer writing all kind of poor code in event handlers and application becomes unresponsive, so he is advised to use ApplicationProcessMessages, and he sprinkles his code with those and application might work better (seemingly). In the reality, he learned nothing, his code is really bad, and sooner or later when some user clicks something unexpected everything will fall apart. When you have to move code to the background thread, you need to think more about it and you need to isolate it better. Mere process of isolating functionality will make that code better. Now, you can still have developer that will just move the whole thing to the background without doing any of that, but that code will not seemingly work (that rarely happens) and it will not work properly, which will hopefully trigger the developer to ask for help and learn how to do that properly. There is a difference. If the UI reacts slowly that means when you drag the window and it will not drag smoothly, when you click the button you may not get immediate response, so you will click it again. Background thread does not block the UI so it does not matter how long it takes to cancel the operation. You can write your code in such manner that when action is canceled, user can immediately continue doing something else. You don't have to move data between threads - data is not contained within threads (unless you specifically create thread local data), you just need to prevent multiple threads changing the same data simultaneously.

This is bad idea. First, Application.ProcessMessages has some global side effects that can bite you in behind when you least expect them. Next, depending on the code, it is possible that some pieces still take too long to keep UI fully responsive. Using background threads for simple operations is not rocket science and at the end when you take all pros and cons it is not more complicated than using Application.ProcessMessages.

function (const arr: TArray<T>): RecWithTwoFields (Pointer, Integer) Bonus: inlining that function looks like this - go go eax, you got it eventually!

There's no supported way to do what you want and that's a good thing.

Just buy Dalija's book "Delphi Event-based and Asynchronous Programming" It is very good in explaining all the pitfalls and a real bargain for all the knowledge that it carries.

I currently have API 29, but I am testing Delphi Android applications only on Android 7.0 device. I am not actively developing on Android with Delphi. When I started Delphi for Android was not suitable for my use case and didn't have support for devices I needed, so I had to use Android Studio.

Upgrading the SDK opens possibility for incompatibilities. Applications with lower SDK version run in compatibility mode on newer versions of the OS. When you increase SDK version you are basically saying this application supports all new OS APIs. If your application (that includes RTL and FXM) does not support all new APIs it can crash or malfunction. See: https://quality.embarcadero.com/browse/RSP-27218 This issue has been resolved in 10.4 Sydney and Android 11 is now officially supported by Delphi. I am not sure if there are any other issues.

I believe you will still have to get familiar with Windows Desktops: Desktops - Win32 apps | Microsoft Docs

The login screen is an entirely different "desktop" (not to be confused with "Virtual desktops" which were introduced with Windows 10), much like an elevation prompt ("user account control"). An application that runs without administrative privileges cannot access that "secure desktop" the login screen is running on. You can, for example, also see this with other solutions like TeamViewer or AnyDesk: When they don't have administrative privileges and the user locks his account, they can't do anything.

I'm sure there is (pirated surely so no further discussion). Obviously they're not made by magicians so you can make it yourself as well (I remember there was software called Thinstall for such purposes). I'm not sure it will be strictly legal but if you own a legal copy, at least your conscience will be clear

exmailx45: I can't use TDBEDIT for android, how do I do?

@ewong You should not, under any circumstances, update vcl controls in a thread other than the main thread. If it's just updating a progress bar, you can do that quite simply by using PostMessage and send a user message to the form https://www.cryer.co.uk/brian/delphi/howto_send_custom_window_message.htm Use PostMessage (non blocking) rather than SendMessage (blocking). Working with threads in Delphi is harder than it needs to be. I recommend taking a look at https://github.com/gabr42/OmniThreadLibrary I also created a nice wrapper for omnithread that makes running tasks in background threads really simple : https://github.com/VSoftTechnologies/VSoft.Awaitable I've been using this in my projects for a while now (I was already using OmniThread) and it makes things so much simpler!

Place the cursor somewhere inside the method and press CTRL-W repeatedly until the whole procedure is selected. Standard IDE functionality.

First, as we all know (I hope) if application cannot process messages, it becomes unresponsive and OS (and user) can kill it, because it may look like it is dead. Application.ProcessMessages pumps the message queue so the OS can see that application is still alive. There are few problems with that approach. Most obvious problem is that such code becomes re-entrant. That can cause some nasty side-effects depending on the code you are executing. But main issue is that you are still running slow operation in main thread, and no matter how much you are able to interrupt that execution with calls to Application.ProcessMessages, this will still slow down UI processing and application may respond to user input slowly. Also, this is not just the problem with reacting to input, but all the calls to Application.ProcessMessages will make that long operation running even longer. Next issue that is often overlooked is that some parts of the long running process may not always execute fast enough. Imagine connecting to some web service and retrieving some very small amount of data. In perfect conditions that may take blink of an eye, but if connection is bad for any reason, this operation can block the main thread for much longer. And Application.ProcessMessages will not help you with that. Also, for cross-platform development, this is more important because mobile devices will kill non responsive application much faster. On Android you cannot even freely perform network operations in the context of the main thread because OS will thow exception if you try. Also on android Application.ProcessMessages no longer works and can deadlock the application.

Found! On the Kastri page, you have to click on "Code" before you can Download. (Beats me, but it rhymes.) NOW I can start to get some understanding.

The correct word is "Warror", sometimes also called "Errning" /s

That is useful if you get paid by the LOC compiler generates-

Am I the only one annoyed that these are in System.Math?

Install to Vm, take Vm file wherever you want = portable enough?

I have no idea what you are talking about. Those were MinValue and MaxValue. I'm really struggling to find any sense in any of your comments.

bug

I mean that the secure desktop cannot be programmatically controlled from another session and desktop. This is a security measure in Windows and not even a system user can get around that.

Dear visitors, I like to notify you that new version of NextSuite is available. Detailed info can be read on: News Article As Easter is near, we are also offering 35% discount on all our components. Just enter EASTER coupon code while ordering. NextSuite includes always growing set of VCL components. Most important components are: NextGrid6 (StringGrid/ListView replacement, written from scratch). NextDBGrid6 (Db variant of the grid) NextInspector6 - An object inspector component. Next Collection 6 - A set of smaller components that are both useful and easy to use.   and many more.  Few screenshots:      Download big demo project from: http://www.bergsoft.net/downloads/vcl/demos/nxsuite6_demo.zip