by cncdrive » Sun Oct 14, 2018 9:10 am
The exec.Wait function is simply a cycle of Thread.Sleep function.
How it works is that there is a code cycle with Thread.Sleep(1); and the time is measured in each cycles and when the parameter of the Wait elapsed then the cycle ends.
It was made like that because the Thread.Sleep is not very precise, so e.g. a Thread.Sleep(50); is often 50-60msec and not precisely 50msec.
If the sleep time in each cycles is 1msec and the time to break out of the loop is measured then it will be more precise, in the 50-51msec range, but I think I don't have to describe this more, it should be understandable.
One more thing is that the Wait is skipped/breaks out of the loop if the macrostop is set, if a STOP or RESET was executed, because otherwise the code execution would stuck until the Wait ends even if a STOP or RESET was requested by the user which would be annoying.
Thread.Sleep is a very basic command in Windows programming, so if it has a problem then that is a Windows issue which I have never seen.
And since macroloops are fully separate threads they will not wait for eachother, they running virtually independently, they will not wait for eachother when there is a Sleep or Wait is coded.
A Sleep puts only the particular thread (macroloop) into sleep in which the Sleep was executed.
Thread.Sleep is not a bad practise in my opinion, there are things which can't be done without it. What is a bad practise is to make the UI thread to sleep, because that freezes the UI.
But the macroloops are not in the UI thread, they are separate threads running in the background independently from the UI thread.