Just to clear a few things up...
Construct runs each tick like this:
- Run the events to completion
- Run any waits that have expired
- Draw the screen
This means if you have a long-running loop in your events that takes 5 seconds, it gets stuck on step 1. Since the engine is tied up in an event loop it never gets as far as checking if any waits have expired, nor does it get to draw the screen - so you can't show any progress during a loop.
This is exactly how many other programming languages work, including JavaScript - for example if you add a "click" handler on a button for a web page, and in that handler run a loop that takes 5 seconds, the browser never gets as far as redrawing the screen (or running any timers), and so the web page will appear to hang for the user. It's a common architecture since everything has to be done in a series of steps, each step is not interruptable (otherwise you get bugs involving half-baked states), and it's largely done on the same thread (since multithreading large and complex programs is extremely complicated and highly error prone). So the way Construct does this isn't at all unusual.
The ideal solution is to actually run the work on another thread, but Construct doesn't support that yet, given the extreme complexity of the feature and questionable feasibility - see this blog I wrote a few years ago on Why do events only run on one core? Therefore the next-best solution is just to run the work in chunks, so the engine has the chance to periodically continue to the other steps needed to run a tick, including drawing the screen.
An obvious way to do this is to run a fixed number of iterations, like 100000 per tick. However this isn't ideal since on very fast systems it will complete the work early, and sit idle while it waits for the next tick, meaning it doesn't complete as fast as it could; and on slow systems that amount of work could still be enough to make it noticably slow.
So really the best approach is to do work for an amount of time. So you'd break up work in to chunks of 15ms, for example. This means fast computers get more work done per tick, and slow computers just take longer, while also allowing the possibility to reach 60 FPS if everything else is fast. But! 'Wait' events don't run during loops, so you have to use a timer value that can update during a loop... and in Construct, that's the wallclocktime expression. So you should save that time at the start of the loop, and then repeat until wallclocktime is greater than startTime + 15ms.
Also...
In Delphi, there's a repeat:until loop which is a lot like a while.
As I pointed out in the thread you linked to, this is supported in Construct. A 'While' followed by another condition is equivalent to 'Repeat until condition false'.
The difference between those is, in a while loop, if the condition is met anywhere in the middle, the loop breaks.
Almost every programming language I've ever heard of only checks loop conditions upon repeating the loop - so this would be an unusual design if it is the case. The reason most languages only check conditions upon the repeat is that if they can break *anywhere* inside the loop, it makes it extremely slow, since it has to keep doing "is condition false" checks after every single statement, which can be a lot of extra work. So that design would basically make it impossible to write efficient loops.
Also 
newt or anyone else who says "just use JavaScript" - that is not really helpful in this forum. There is a separate scripting forum for people who want to use JavaScript. In any posts outside of that forum the assumption should be they are working only with events and only want help with events.