Construct ought to use a multithreaded runtime, but it doesn't. It's a design flaw and fixing it would require some level of refactoring. It's also a problem in the editor - saving or loading huge projects sends the editor in to "not responding" as well. It's solved in Construct 2 - the editor does heavy lifting on a separate thread, and most browsers run javascript in a separate thread too.
But why does your game need to do such an extraordinary amount of processing that the window is locked up? It seems unusual.
The "DoEvents" type function that was in VB is widely regarded as an ugly hack, but I guess that wouldn't be out of place in Classic
The only other solution is to break up the work over multiple ticks. For example, instead of doing a million loop iterations which takes ten seconds and goes in to "not responding" mode, break it up in to 10,000 iterations per tick over 100 ticks. Not only does this keep the app responding during the processing, but it also gives you the opportunity to update the screen with the progress. That's probably your best bet for the time being.