Indicators run in worker (non-UI) threads. UI thread is only one, the main one responsible for UI. And do not abuse ThreadSleep(). It is not meant to delay execution for seconds. It is meant only to introduce single millisecond delays.
@bobptz just out of curiosity. Why did you even think of using ThreadSleep(100) for delaying the execution of the code? If you for example use:
for(i=1; i<=10; i++) ThreadSleep(100); // Do not use it!
... it makes the whole indicator unresponsive (in this case) for one second. So it's a very bad solution. There are many ways of executing some parts of the code conditionally or every n seconds or delaying the execution for some time, without making the indicator sluggish or not responsive ...
OK thanks for the info. I'm not sure what is the wider context of your whole code, so my suggestions might not be relevant, but I simply wanted to encourage you to replace (in most cases) using ThreadSleep() which freezes the execution of the whole code with some alternatives which don't make the whole code unresponsive. For instance, you can repeat or delay executing some parts of the code using Status("redrawaction") and/or GetPerformanceCounter(). If you need to wait 0.5 or 3 or 10 seconds, the code will still be responsive during the waiting period. Take a look at some examples:
So don't hold the execution of the whole code. There's really no need to do that! Just check every n seconds (or even fraction of a second) if some condition is met and only then run another part of the code. To run another script conditionally, you can use ShellExecute(). During the waiting period, your code will still be responsive.
Alternatively you can also use Batch window ( Execute And Wait) or OLE to sequence tasks and make one formula execute only if the previous one has finished.
UI thread is the main application thread, the one that is started by Windows itself when application starts. It is main application thread responsible for handling UI, i.e. menu, buttons, dialogs, mouse clicks, etc. As an end-user you don't have direct programmatic access to it (even Gui* functions don't live in UI thread and only 'communictate' with UI thread).
The AFL can be run in worker (non-UI) threads and in main UI thread. There are some cases when AFL is run from main UI thread (for example when you press "Reset all" button in the Parameters)
or when using OLD Automatic analysis. In such cases ThreadSleep does nothing to prevent locking UI (since sleeping UI thread is HUGE no-no as it blocks entire app).
"Normal" applications like say Notepad or Calculator, have only one thread, the main UI thread.
Only multi-threaded applications have non-UI threads.